「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

Hnoss

English⇒Japanese

acai

English⇒Japanese

jhoo0509

English⇒Japanese

yoko

English⇒Japanese

ホーム新着翻訳記事一覧 > 新着翻訳記事

新着翻訳記事

GitLab Pagesでコード網羅率を公表する | from about GitLab.com / Grzegorz Bizon

 2016年11月3日投稿 

  ← エンジニアリング関連記事

 GitLabでは、皆さんのコントリビュート(アイデア投稿)をお待ちしております。もちろん、どなたでもご参加いただけるのですが、我々としては、より幅広いを募集するために、コードの正誤判定テストを自動的に実施します。
 たとえば、初心者の方が多少ルールを間違えたコードを提出してきたとしても、間違った箇所さえ訂正すれば、見かけより良い案だったということが多々あります。自動テストを使えば、そのコード上の誤りを効率的に発見できるのです。我々はこの仕組みが、開発参加者の枠を広げる一助になると考えてます。
 

  しかし、それには実用に耐えうるテストスイートを作り上げなくてはならなりません。ソフトウェアの信頼度を高め、更なる改良につなげる道しるべとなるのですから。

 

  コード網羅率とは?

  ソフトウェアのテストスイートで使われている手法に、コード網羅率の計測というものがあります。

  コード網羅率計測ツールは、たいていのソフトウェアテスト環境に搭載されているものです。そのソフトウェアの出来具合を、ソースコードを読み取って、開発者に解りやすく伝えます。ここで大切なのは、出来栄えのパーセンテージにこだわることではなくて、直すべきところがあるかどうか、またそれは具体的にどこなのかを測定できるというところです。

  ツールによっては、コードの計測結果をHTML形式に変換して、ブラウザで確認できるようにしてくれるものもありますので、そちらの方がコードの修正箇所と、改良につながる部分を簡単に把握できるでしょう。

  ここでは、GitLabの開発でも使われている Rubyのコード網羅率を計測する手法で、GitLab Pagesプロジェクトに不備がないかどうかを確認する方法を紹介します。
 (写真1)コード網羅率 計測結果

 

  どうやってコード網羅率を計測してるの?

  だいたい、どのプログラミング言語にも、それ専用のコード網羅率計測ツールが用意されています。それぞれのニーズに合ったものを探して使いましょう。これはGitLabでの話ですが、Rubyを使っているプロジェクトに対しては、だいたい「SimpleCov」というツールを利用していることが多いですね。

  でも、利用するツールは、「○○さんが使っているから、これにしちゃえ」というよりは、きちんと説明書きを読んで、どのようにしてコード網羅率を算出しているのかも、ある程度理解してから選択することをお勧めします。

 これから紹介する方法は、「SimpleCov」を使ってGitLab Pagesの質を確認する方法になりますが、「ローカル環境で、どのようにして問題点を計測して、修正を入れるか」の大まかな手順として参考にしていただけると嬉しいです。
 

  次の例では、RSpec と SimpleCovを併用していきます。

 

  テストツールの設定

  「SimpleCov」の設定は実に単純です。「spec_helper.rb」というファイルに、次の設定を加えます。

======================
require 'simplecov'
SimpleCov.start
======================
  この設定をすれば、あとで rspecコマンドを発動したときに、SimpleCovのテストが自動的に開始されるようになります。
 RSpecは、基本的に以下のコードを実行します。単純ですが、これでシングルクラスのテストを実施してるんですよ。

   spec/dog_spec.rb

======================
describe Dog do
 it 'barks' do
  expect(subject.bark).to eq 'Woof, woof!'
 end
end
======================
 

  dog.rb
======================
class Dog
 def bark
  'Woof, woof!'
 end
end
======================

 RSpec ハーネスでは、出てきた計測結果を次のように表示します。

======================
Dog
 barks

Finished in 0.00058 seconds (files took 0.08804 seconds to load)
1 example, 0 failures

Coverage report generated for RSpec to /tmp/coverage_example/coverage.  6 / 6 LOC (100.0%) covered.
======================
 出力されたテスト結果は、「coverage/」ディレクトリに収納されます。次のコマンドを使えば、後からでも計測結果を確認しなおせます。
 

======================
$ ls coverage/
assets/ index.html
======================

  はい!これにてHTML形式で、コード網羅率が表示されますから、GitLab Pagesで公表することも造作ありません!

 

  コードテストを GitLab CI で自動化しよう

  この章の説明は、「.gitlab-ci.yml」ファイルの使い方について、少し知識を持っていただいていると、より様々なプロジェクトに応用できるかもしれません。

  GitLab CIを使うには、「.gitlab-ci.yml」というファイルに、いくつか設定が必要ですが、GitLab Pagesのコード網羅率レポートを閲覧する時にも便利です。
 

  設定1. まずは RSpec テストツールを起動させる

  プロジェクトにプッシュしたら、途端にテストツールが動いた方が効率的ですね。早速、次の設定をファイルに書き込みましょう。これから、たくさんの設定が加わりますが、まずこれがベースの設定となります。

======================
image: ruby:2.3

rspec:
 script:
  - bundle install
  - rspec
======================

  設定2. テスト結果の保存先を指定する

======================
image: ruby:2.3

rspec:
 script:
  - bundle install
 
 - rspec
 artifacts:
  paths
:
   - coverage/

======================
  なんと、ここでは、テスト結果のレポートが、アーティファクトとして扱われます。よって、このようにビルド先を指定しないと、正しい場所にHTMLファイルが保存されません。「build」サイドバーから、build artifacts ブラウザを使うと、正しい場所にテスト報告書が置かれているかどうかがわかります。
 (写真2)コード網羅率 のHTMLは、このようなところから確認できます。

 

  設定3. 最後に、GitLab Pagesと共に公開する

  GitLab Pagesの使い方はこちら

======================
image: ruby:2.3

rspec:
 script:
  - bundle install
 
 - rspec
 artifacts:
  paths:
   - coverage/

pages:
 stage: deploy
 dependencies:
  - rspec
 script:
  - mv coverage/ public/
 artifacts:
  paths
:
   - public
  expire_in: 30 days
 only:
  - master

======================
  GitLab Pagesでコード網羅率を公開しようとするなら、job同士のステージを分割しなくてはなりません。
 ステージは、主にtestbuilddeployの三種類があります。(必要に応じて別のステージを設けることができる。)
 それから、GitLab Pagesを立ち上げる限り、job名「pages」は欠かせませんね。

  「dependencies」というキーワードを使っているので、GitLabはサイトをビルドする時に、job名「rspec」で作成されたアーティファクトを利用します。
 そして、「pages」jobのアーティファクト展開先は、「public/」とされているので、テスト結果は、「coverage/」から「public/」ディレクトリに移動させられるイメージを持つと、分かりやすいでしょう。
 GitLab Pagesは、「public/」に入れたものしか、ウェブサイトの材料として見なしてくれませんので、大事です。

  網羅率レポートページをデプロイするのは、masterブランチにプッシュされたときに限定するとよいので、only: -master という項目を、コンフィグファイルの最後に設けています。
 「expire_in: 30 days」とある通り、アーティファクトの有効期限は、30日間です。この日数が経過すると、コード網羅率の結果は無効化されます。

 

  同時並行テスト

  設定はやや複雑化しますが、他のテストスイートを同時に作動させることはできます。

  GitLab には、同じステージにあるjobを同時に実行する機能がありまして、テストjobが複数あるのなら、stage: test という設定を設けるのが適当と思われます。
 また、同じような工程を『同時に実施することで、テストやビルドにかかる所要時間を削減することにつながりますので、CIパイプラインに、jobのステージを明記しておくメリットはあるでしょう。

  ここで使用する試験方法には、様々な種類があります。
 もっとも単純なもので、手動で何らかのテストコードを実行してしまうもの、あるいは、既成のツールやプラグインをテストに利用することもできます。

  テストスイートが複数個あるのなら、生成される網羅率レポートには、それぞれ差異が発生することがあります。もちろん、どのテスト結果もbuildアーティファクトとして、指定されたディレクトリにビルドされることになりますよ。それらの計測結果は、他のjobで実施されたテスト結果と合流して、総合結果がアカウントの中に報告されることとなります。この工程にも支障が出ないように、テストには、testステージを設けてください。

  GitLabでは、基本的に自前のテストスイートを多用していますが、必要に応じては配布されているテストスイートをjobに取り入れています。
 たとえば、SimpleCovなんかは、その代表例ですが、このプロジェクトはソースこそ公開しているものの、外部からのマージは受け付けていないので、GitLab仕様にパッチを仕立てる必要がありました。このパッチにつきましては、SimpleCov本家様にも取り入れてもらえないかどうか、イシューを出しています。

 

  GitLab Pagesとして 網羅率レポートをデプロイする

  新しく変更を加えた「.gitlab-ci.yml」をGitLabにプッシュすると、新しいjobがCIパイプラインに表示されます。
 (写真3)カバレッジ・レポートの行方と、デプロイジョブの結果

  「pages:deploy」jobが成功しているようなら、ステータスアイコンが緑色になっているはずです。
 網羅率レポートにアクセスする番地は、「http://ここにグループ・パス.gitlab.io/ここプロジェクトパス」となるので、「https://gitlab-org.gitlab.io/gitlab-ce」みたいになりますね。

  そのアドレスに表示されているレポートは、その前にプッシュしたての最新版ですよ!

 

  コード網羅率レポートバッジを使う

  GitLab Pagesの網羅率を公開したら、そのリンクをどこかに設置したくなるものでしょう。
 そんなときに、コード網羅率レポートバッジを設置することをお勧めしております。ご自分のREADME.mdファイルに置いてみてはいかがでしょう。
 

  たとえば、我々のプロジェクトなら、こちらのREADME.mdに、バッジが沢山貼られていますね。
 (写真5)コード網羅率レポートバッジ

  このバッジをクリックすると、コード網羅率報告書のページが開くようになっています。
 ここで使われているマークダウンソースは、以下の通りです:

============================================
[![Coverage report](https://gitlab.com/gitlab-org/gitlab-ce/badges/master/coverage.svg?job=coverage)](http://gitlab-org.gitlab.io/gitlab-ce/coverage-ruby)
============================================   レポートバッジについて、もっと詳しく知りたい方は、こちらのドキュメントをご覧ください。

 

  おわりに

  コード網羅率は、ソフトウェアの質をあまりに分かりやすーく表示してくれるものではあります。かといって、それがソフトウェアの動作を保証するものではないし、他に良いテスト基準があるのなら、どんどん取り入れるべきです。ただ、そんな完璧とは言い難いものでも、大それた間違いを探すのには、大役立ちで、それがコードの投稿を促してくれる面があります。
 

  GitLabには、まだまだ改良しやすい部分がありますから、皆さん、どんどんコントリビュートしてください!

  原文記事をツイッターで共有する

PDF
更新日:2018-05-17 23:41:28 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://about.gitlab.com/2016/11/03/publish-code-coverage-report-with-gitlab-pages/ Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

【GitLab 公式 を訳してみた】GitLab UX ガイド

GitLab Documentation > GitLab development guides >GitLab UX ガイド  現在、UX documentationの内容を、 design.gitlab.com projectに移行しております。この説明書の更新…2018-05-26 14:48:52

【GitLab 公式 を訳してみた】GitLab UX ガイド>デザイン原則

GitLab Documentation > GitLab development guides > GitLab UX ガイド >デザイン原則  これから説明するデザイン原則は、GitLabの使い勝手が均一されるように制定されました。 …2018-05-26 14:47:51

[翻訳]GitLabハンドブック>エンジニアリング

現在の位置: チームハンドブック 目次 >エンジニアリング   連絡方法 Public Issue Tracker (GitLab CEの場合) ; 不特定多数に公開しては問題が発生するような一部の題材に…2018-05-26 00:10:26

[翻訳]GitLabハンドブック>UX部門

現在の位置: チームハンドブック 目次 >UX部門   UX ガイド  GitLabの見た目は、 UXガイド を基準に構成されている。このガイドが、わが社におけるデザインの原論、表現法、…2018-05-26 00:09:10