というエントリが日頃考えていることと内容がマッチしていたので興味深く読んだ。
そこからたどって以下のエントリも読んでみた。

• The first 2 hours of TDD are the most painful – Chad Myers’ Blog
• ThoughtStream.Create(me); : In response to Chad Myers’ TDD questions

「TDDに関する本やブログを読みあさったけど意味がなかった」「そばによいペアがいればそんなことないんだけど」などといったコメントが印象的。
やっぱり経験者とのペアプロが一番いいんだろうなぁ。百聞は一見にしかずということで。

自分もたまに「テストってどう書いたらいいんでしょう？」みたいな質問をされるのだけど、明確なアドバイスを返せないでいたのでこれを期に考えてみた。

まず経験者が周りにいるならペアプロするか、プログラミングしているところを見せてもらうのが一番いい。

経験者が身近に誰もいない環境で始めるのならば、意味があるのかとか役に立つのかとか考えずテストを書き続けるのがいい。
たぶんテスト駆動開発にチャレンジしてみたけどなじめずやめてしまう人というのは、ちょっと試して効果を実感できないうちに疑問を感じてやめてしまうケースが多いと思われるので。

また何に関してテストを書いたらいいのかわからんと思うけど、とりあえずテストのシンタックスに慣れる意味も兼ねて、シンプルにすべてのメソッドに対してひとつずつテストを書く。
愚直に数ヶ月書き続けることで自然とわかってくることがあるだろう。

わかるまで手を動かすという方法は効率は悪く感じられるかもしれないけど確実ではある。それに実は思ったほど無駄でもないはず。
繰り返しになるけど効率を求めるなら経験者を捕まえていっしょにキーボードの前に座るのがベスト。

座学より実技で。

モックとはスタブとは

Martin Fowler’s Bliki in Japanese – TestDoubleの定義がわかりやすいので引用。

スタブは、テスト時の呼び出しに対して、あらかじめ用意された結果を返す。
通常、テスト用にプログラムされたところ以外には応答しない。
スタブは呼び出しの情報を記録することもある。
例えば、Eメールゲートウェイスタブは「送られた」メッセージを記録するような場合だ。
単に「送られた」メールの数を記録する場合もあるだろう。

スタブによってデータベース接続やネットワークIOなどの要素をテストから分離することができる。
また時間のかかる処理をスタブで置き換えることによってテスト時間を短縮することにも使われる。

モックは、エクスペクテーションが事前にプログラムされたものである。
エクスペクテーションとは、受信する一連の呼び出しの仕様を表わしたものである。
期待されない呼び出しが行なわれた場合は例外をスローする。
また、テスト実行後の検証 (verification)で、期待された呼び出しがすべてきちんと行われたかどうかを確認する。

Railsで言うと、例えばコントローラのテストではモデルのモックを使ってコントローラがモデルを意図したとおりに使っているのかというところを検証する。
実際のモデルの代わりにモックを渡してコントローラがそれをどう使うかを見るわけだ。
モックは自分がどのように使われるべきかというエクスペクテーション（期待）を持ち、それと実際に自分が受けた扱いを比較して検証を行う。

モックによってモデルがなくてもインタフェースが決まっていればコントローラのテストを書いていけるし、逆にモデルの内部に直接手を突っ込むようなコードが書けないのでお互いの仕事が明確になるという効果もある。

これで理解が難しい場合はコードを書いてみるとわかると思う。コードの書き方については最後にまとめた参考サイトを参照。

モックとスタブの効能

モックとスタブを使う利点はいっしょに動作する個々のクラスやオブジェクトを（例えばコントローラとモデルおよびビュー）を完全に分離してテストできるという点だ。
それはお互いの役割をより明確にできて、よりシンプルかつ堅牢な設計にできると言うことでもある。

最初、モックとスタブを使い始めて既存のテストに適用しようとするとうまく組み込めなかった。
コントローラ内でモデルのモックを使おうとすると、エクスペクテーションが複雑になりすぎてどうにもうまくいかない。

これはモデルの中にもっと処理をまとめてインタフェースを単純化することで解決することができた。
結果、コントローラの中身がすっきりして見通しがよくなりメンテナンス性が上がったように思える。

今まではコントローラがモデルに細かくあれこれと口を出して動かしていたのが、今では一言かけるだけでモデルがテキパキと動くようになったみたいな。
「まかせれば人は楽しみ動き出す」ってやつだね。違うな。まあいいや。

とにかくモックやスタブによって自然と設計がよくなると思う。

モックとスタブの書き場所

サンプルコードは世にたくさんあるので特にここでは書かないがひとつだけ。
RSpecでモックとスタブを書き始めるときにちょっとだけ悩んだのが、モックとスタブのコードをどこに書くのか？というところ。
そこだけメモっておく。

これはテスト対象の処理の実行の前に書く。
すると処理の中でモックやスタブが使われるというスンポーだ。

そして以下の例ではindexアクションの処理の中で@item.some_methodが呼ばれていればモックのエクスペクテーションをパスする。

it "なにかのテストですよー" do
  # モック
  @item.should_receive(:some_method)

  # テスト対象の処理
  get :index

  # 普通のRSpecのエクスペクテーション
  @items.should be_true
end

参考サイト

• RSpec-1.1.3: Mock Objects
• RSpec-1.1.3: Controllers
• Ruby on Rails でのモックとスタブの作成
• Martin Fowler’s Bliki in Japanese – TestDouble
• Young risk taker.: [rails] 実践RSpec on Rails – コントローラとモデルのBehaviourを書く
• Rspecでコントローラのspecファイルを書く – kaeruspoon

参考サイトを見て実際手を動かすのが理解の早道という気がする。

例えば次のようなフィクスチャがあり

first_feed:
  id: 1
  title: hoge

次のような更新のテストを書くと

post :update, :id => @first_feed.id, :title => 'hogehoge'

@first_feed.title.should == 'hogehoge'

更新処理（updateアクション）が成功してもこのテストは失敗する。
@first_feed.titleは”hoge”のままだからだ。

期待通りの結果にするには次のようにしなくてはならない。

post :update, :id => @first_feed.id, :title => 'hogehoge'

@first_feed.reload
@first_feed.title.should == 'hogehoge'

これはなぜかというとデータベースの更新が@first_feedとは別のActiveRecordインスタンスで行われるため。たぶん。

更新処理内で同じレコードを参照する別のActiveRecordのインスタンスが作られてデータベースの更新はそちらで行われる。
他のインスタンスによる変更を既存のインスタンスであるところの@first_feedが知るすべはないので、リロードしてやらなければならないというわけだ。

というわけでフィクスチャの、と言っているが実はフィクスチャ以外でもこの現象は起こる。
でもテスト時は特にフィクスチャでよくやる。

で、初心者のハマリがちなところとか偉そうに行ってる割に自分自身が昨日これで30分くらいはまってたわけだが。

@first_feed.itemsにアクションで変更が発生したときにも@first_feedをリロードしないといけないんだぜ。
あと長時間の連続コーディングもNGなんだぜ。

violated

Test::Unitにおけるflunkと同じようなもの。

it のブロック内に内に書くとそのテストケース（Example）は必ず失敗する。

it "昨日布団の中で思いついた仕様" do
  violated
end

さっさとテスト書けよというプレッシャーが漂う。

pending

テスト自体や実コードの実装の保留状態を示す。

it のブロック内にpendingと書くと、その行以降の処理は実行されない。
pendingメソッドを使うときには引数に必ず理由を書かなくてはならない。

it "一昨日風呂の中で思いついた仕様" do
  pending("やんごとなき理由")
  # 検証されないエクスペクテーション
end

またpendingにはブロックを与えることができ、その場合はそのブロック内の処理だけがペンディング扱いになる。

it "こないだバイクに乗ってて思いついた仕様" do
  pending("大人の事情") do
    # 実コード未実装のため例外が出るエクスペクテーション
  end
end

こちらはpendingブロック内のエクスペクテーションがすべてパスすると逆にテスト失敗とみなすようになる。
pendingなのに通るのはおかしいと言うことだろう。

未実装によるpending

it にブロックを与えなかった場合には自動的にpendingになる。

it "先日散歩してて思いついた仕様"

仕様だけ先にぱぱっと書いてしまうとpendingの多い状態になるだろう。
しかし強制的に全部失敗と言われるよりは気楽に仕様をどんどん書いて行けそうだ。

使い分け

violatedとpendingの使い分けの一般的なポリシーがいまいちわからない。

これだけはどうしても今日中に実装しなくてはならない！といか言うときだけviolated使えばいいかんじかな。例えば緊急度の高いバグ対応用のテストとか。
あとはpendingにしといて粛々と実装。

まあとりあえず最低限チーム内でどういう扱い方をするか合意がとれていればよさそうだ。

「保留」の意味合い

最終的にはpendingもゼロを目指すのがやっぱり本筋なんだろうな。
「状況が変わらない限りずっとペンディングの機能」とかは多分ペンディングのレベルが違うのでいったんテストごと削ってしまうのがクリーンな気がする。

「テストの保留」および「近く対応すると決まっている実装の保留」であって「機能を実装するかしないかわからないから保留」とは違うと区別していた方が幸せになれそうだ。
やっぱり全部グリーンにならないと気持ちよくないもんな。

参考

Rubyist Magazine – スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)

RSpecはTest::Unitに比べて書きやすく感じる。
直感的に書けるというか。

RSpecを使うようになってから、仕様をテストコードとして書いてからプロダクトコードを書く、という流れが自然になった。
多分テストコードを書くストレスが減ったせいかと思う。

コーディングの最初に考えた仕様やまたはコーディングの途中で思いついた仕様をテストコードに

it "一覧はポイントの高い順に表示"

といった風に日本語でどんどんメモ感覚を書いていけるというのが大きいようだ。

Test::Unitでもコメントで同じことは実現できると言えばそうなのだが、それは自然とは思いつかない。
また日本語で仕様を書くのとは別にテストメソッド名を英語で考えなくちゃならない。

RSpecでは何も考えなくてもSyntaxがそういう流れを方向付けてくれるし、メソッド名を考える必要もない。
この差は大きい。

ここまで考えてきて言語やフレームワークのSyntaxはUIと同じなんだなぁ、とふと思った。
よいSyntaxはよいUIと同じってことだね。

手順

• StoryとScenarioを書く [プレーンテキスト]
• Stepを書く [Rubyコード]

テストコードを書く前にテキストで仕様を書く。
テストコードはその仕様にあわせて書いていく。

ファイル構造は以下の通り。

• stories/hoge/hoge – StoryとScenario
• stories/hoge/hoge.rb – Stepをまとめて実行するためのコード
• stories/hoge/hoge_steps.rb – Step

今のところ標準でこのひな形を作るジェネレータは用意されていないが、Storygenで生成できる。
多分これはそのうちマージされるのかな？

StoryとScenarioを書く

Storygenで生成されるひな形のStoryとScenarioは以下の通り。

Story: put your story name here

  As role
  I want feature
  So that benefit

  Scenario: everything is cool
    Given precondition
    And   another precondition
    When  action
    And   another action
    Then  outcome
    And   another outcome
    

英語だとまったく素敵に自然に書けるっぽい。
だが私は母国語を愛している。というわけで以下。

Story: ショッピングカートで買い物をする

  アクター：ユーザー
  目的：ショッピングカートにものを入れて中身と合計価格が確認できる
  結果：安心してお買い物を楽しめる
  ※ ここは自由記述っぽい As, I want, So thatをそのまま残すか悩んだけど消した。 

  Scenario: ショッピングカートにものを入れる
    Given ショッピングカートには何も入っていない
    And   りんご は単価 100 円
    And   みかん は単価 80 円
    When  ユーザーは りんご を 3 個カートに入れる
    And   ユーザーは みかん を 5 個カートに入れる
    And   ユーザーはショッピングカートの内容を確認する
    Then  ショッピングカートの合計価格は 700 円
    And   ショッピングカートには りんご が 3個 入っている
    And   ショッピングカートには みかん が 5個 入っている
    

以下備考。

• Scenarioはこの後に続けて複数書いていける。
• Given, When, Thenは単純に上から順に実行される。
• Thenの後にまたWhenを書いてつなげていくのも可。
• 単語や数値だけ変えた同じ形の文はStepで再利用できる文になる。
• 単語や数値は半角スペースで他と区切る（英語だったら自然に単語で切れる）
• Scenarioが異なってもStepは再利用できる。
• Scenarioの文の内容を変えるとStepの方も変えなくてはならない。これは若干めんどい。

Scenarioの量が増えるとStepの再利用率が高くなっていいかんじになる？

Stepを書く

Scenarioがまとまったらそれに沿ってStepを書いていく。

Givenには前提条件。
Whenにはアクション。
Thenには結果を書く。

これは紳士協定的決まりで、どの種類のStepに何を書かないとエラーになるとかそういうことはない。
Givenに前提条件の準備からアクションから結果の検証まで全部書いちゃうこともできるし、頭にいきなりThenと書いてその後ろに前提条件を書いたりもできるのだが、まあそういう変なことはしない方がいいだろう。

Given

前提条件。

商品データの準備。
一応ショッピングカートに何も入ってないことも確認。

# Precondition steps / Given
steps_for :hoge do
  Given "ショッピングカートには何も入っていない" do
    get "cart/show"

    response.should have_tag('span[class="no_item_message"]')
    response.should have_tag('span[class="amount"]', "0")
    # 一応確認
  end

  Given "$name は単価 $price 円" do |name, price|
    Item.create(:name => name, :price => price)
  end
end

下の方のGivenは「りんご は単価 100 円」「みかん は単価 80 円」に適用される。
こういう仕組みによってStepが再利用できる。

When

アクション。

ユーザーの行動をトレース。
カートに商品を入れて中身を確認する。

# Action steps / When
steps_for :hoge do
  When "ユーザーは $name を $n 個カートに入れる" do |name, count|
    item = Item.find_by_name(name)
    post "cart/add/", :id => item.id, :count => count
  end

  When "ユーザーはショッピングカートの内容を確認する" do
    get "cart/show"
  end
end

ここでは上のWhenが「ユーザーは りんご を 3 個カートに入れる」「ユーザーは みかん を 5 個カートに入れる」に適用される。

Then

結果。

HTMLの内容を確認する。
合計価格とカートの中身の明細。

# Outcome steps / Then
steps_for :hoge do
  Then "ショッピングカートの合計価格は $amount 円" do |amount|
    response.should be_success

    response.should have_tag('span[class="amount"]', amount)
  end

  Then "ショッピングカートには $name が $n 個入っている" do |name, count|
    item = Item.find_by_name(name)
    response.should have_tag("span[class=\"item_name_#{item.id}\"]", name)
    response.should have_tag("span[class=\"item_count_#{item.id}\"]", count)
  end
end

これを書いているうちにひとつ技を思い出した。
HTMLに出力される変数の内容を確認しやすくするために、変数をユニークな名前のidかclassを持たせたspanタグで囲むとよいって技があったのだった。

ストーリーテストの実行

Stepがすべて書けたら以下のように実行。

$ ruby stories/hoge/hoge.rb

rakeのタスクでrake spec:storiesとか言うタスクがそのうちできるのでしょう。
今はないので欲しければ自分で定義するのもまたよしでせうか。

雑感

Scenarioの文の内容を変えるとStepの方も変えなくてはならない、という部分が若干めんどくさいけど、Stepが思ったより再利用できそうだし悪くないかもしれない。
とりあえずしばらく書いてみるかな？

しかしユースケースの書き方とかかなり忘れてるな。

$ ruby script/generate rspec_story hoge
Couldn't find 'rspec_story' generator

だめっぽい。
公式にも情報なし。

そこでぐーぐる先生に聞いてみると以下のページを教えてくれた。

michaelklishin’s storygen at master ? GitHub

すばらしい。
早速RAILS_ROOTのlib/generators以下に設置して使ってみる。

$ ruby script/generate rspec_story hoge
      create  stories/hoge
      create  stories/hoge/hoge
      create  stories/hoge/hoge.rb
      create  stories/hoge/hoge_steps.rb

ジェネレータの名前はやっぱりそれか（´∀`）

対応表

RSpecへ移行した観点からの所見

狭い見識からちょっとした雑感をば。

コントローラのテストが書きやすくなった

Railsの機能テスト（Functional Test）ではコントローラとビューのテストをいっしょくたに扱っていたが、RSpecでは別々になっている。

そのためコントローラのテストが書きやすい。
データベースからの値の取得やセッションの状態の確認、どのテンプレートをレンダリングしているか、httpのレスポンスの結果は何か、などコントローラの仕事だけにフォーカスしてテスト（「Example」と呼ぶべきなんだろうけどまだなじみがないので「テスト」で）が書けるので、ビューテンプレート側での変更などを気にする必要がなくなった。

デザイン変更で機能テスト失敗するようになりましたとか言う凹む状況から解放された。

ビューのテストはいらない子になった

同じようにビューのテストでもビューテンプレートとしての役割だけに集中したテストが独立した形で書けるようになっている。

が、一方でコントローラとビューの連携が正しく働いているかということがテストできなくなった。（ビューが要求している変数をコントローラがちゃんとアサインしているかなど）
つまりコントローラのテストとビューのテストが単体でそれぞれパスしていても、実際動いたときにきちんと動くかどうかはわからなくなった。

この問題に関してはビューのテストをストーリーテスト（User Stories）で対応することが推奨されている。
正しい気がする。

というわけなのでビューのテストは書かないで必要ならばインテグレーションテストのレイヤーに任せようと思っている。
単体での動作を確実に確認しておきたいややこしい処理はモデルとかコントローラにだいたい集まってるはずだしね。

ビューのテストでCSSセレクタが使える

assert_tagでタグの指定をするのはけっこうめんどうだったが、RSpecのhave_tagマッチャではCSSセレクタが使えるのでそれなりに楽になった。

ビューのテストは今のところ書く気がないがストーリーテストでもhave_tagマッチャは使える。

ヘルパーのテストをサポート

Rails標準ではヘルパーを扱うテストはなかったが、RSpecではサポートしている。

従来のRailsでもヘルパーのテストを書く方法は紹介されていたりする（Railsレシピなど参照）が、そういう手法のノウハウがなくても最初から書けるようになっているというのはよいことだ。

ビューの気になる部分をヘルパーに切り出してテスト対象にするとかもありかも。

インテグレーションテスト

これはもともと書いてなかったのでよくわからない。

しかしRSpecのUser Stiriesはメンテするのがけっこうめんどくさい気がしている。
テキストファイルに簡易なユースケースっぽいScenarioを書いてそれに沿ったStepを書くという形式なのだが、Scenarioの文言を変更するとStepの方も修正しないといかんというのがイマイチ微妙（文言をあわせないといかんのです）・・・
慣れればそうでもないんだろうか。

簡単に書けないのならSeleniumとかに走った方が幸せになれるかもしれないな。Selenium on Railsとかもあることだし。
ただまあSeleniumはSeleniumで実行に時間がかかるというネックを抱えているんだが。

インテグレーションテストのレベルになると何をテストして何をテストしないかの取捨選択が肝なんだろうか。

雑感はおまけ程度にするはずがなんか長くなってしまった。

参考

RSpec-1.1.3: Spec::Rails

Rubyist Magazine – スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)

if @item.nil?
  return render(:nothing => true, :status => '404 Not Found')
end

しかし次のようなコードでは if の結果がどちらに分岐してもカバーしているとみなされる。
@itemがnilであるケースがテストされていなくてもカバレッジはパスする。

return render(:nothing => true, :status => '404 Not Found') if @item.nil?

ということなのでif修飾子を使うのはやめた方がよい。おわり。

.
.
.

というのはウソで、カバレッジの厳密さにこだわってコードの書き方を変える必要はないと思う。
カバレッジは所詮目安なんだから。

あと100%である必要もないし、100%であることを強制するのはナンセンス。
中身の薄いテストでも100%にするだけならできるわけなので。

でもまあTDDで開発してたら自然と100%になる気はするなぁ。
100%にする必要はないと言ったけど、100%だったらやっぱり気持ちいいな。
だからTDDは気持ちいい。

うむ、なんだかきれいにまとまった気がする。（ほんとか？）

参考

コード品質を追求する: カバレッジ・レポートに騙されないために

rake spec:rcov

すばらしい。

spec/rcov.opts

rake spec:rcovした時にrcovに与えるオプションはspec.optsで指定できる。

デフォルトの内容は以下。

--exclude "spec/*,gems/*"
--rails 

他人の作ったライブラリなどカバレッジテストの対象外にしたいものは–excludeに追加するとよろしい。

近頃のこと

コカ・コーラのカナダドライ ジンジャーエール エクストラが辛くてうまい。
でもすぐ消えそうな予感もする。

スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)

タイトルからしてジョジョ臭がプンプンしやがる。
それはさておき読み進めてTest::UnitとRSpecの違いを理解。

基本的にやってることは同じなのだが、テストを設計の一部として明確に意識させるために記法などを工夫している。
Test::Unit が「テスティングフレームワーク」であるのに対して、Rspecは「統合テスティング環境」であることを目指している。

ということらしい。

RSpecのインストール

さてとにかく百聞は一見に如かず。
早速使ってみるかとRSpecをRailsのプラグインとして入れようとした段。

$ ruby script/plugin install http://rubyforge.org/var/svn/rspec/tags/REL_1_0_8/rspec

Plugin not found: ["http://rubyforge.org/var/svn/rspec/tags/REL_1_0_8/rspec"]

む、インストールできない。
なんだかファイルがないと言われる。

ぐーぐる先生に聞いてみた。

RSpec をインストールしてみた – Akasata’s Page（あかさたのページ）

たどって本家サイト発見。
いつも思うことだけれども本家サイトがサーチエンジンの検索結果の上位に来てないのは切ない。（※Google.com in Englishではちゃんとトップに来てた）

RSpec-1.1.2: Installation

本家サイトのドキュメントを見たところ現在は以下のURLで入れるのが正しい模様。

$ ruby script/plugin install http://rspec.rubyforge.org/svn/tags/CURRENT/rspec
$ ruby script/plugin install http://rspec.rubyforge.org/svn/tags/CURRENT/rspec_on_rails

インストール成功。
ちなみに「CURRENT」の部分を「REL_1_1_2」とかにすると特定のバージョンを入れることができる。

RSpecを動かしてみる

次は実際動かしてみる。
既存のRailsアプリのディレクトリでRSpecの環境をセットアップ。

$ ruby script/generate rspec
$ script/generate rspec_model Item

これでrspecのディレクトリができてテストの雛形などのファイルが作成される。
モデルのファイルも作ろうとするが、すでにモデルはあるのでmodel/item.rbを上書きするか？と聞かれる。上書きしない。

さて何もまだテストを書いてないけどまず動かしてみたいので実行。

$ ruby script/spec -c spec/models/item_spec.rb

script/spec:4:in `run': wrong number of arguments (5 for 1) (ArgumentError)
        from script/spec:4

これは・・・なんだか動きません。
しばらくいろいろためしてscript/specの引数を削ってみたりしたけれども、そんないい加減なことでは別のエラーが出ただけだった。
さらっと試したいだけなのであんまり深追いする気力はない。

で、ちょっと休憩した後で方向転換して別の既存のRailsアプリで動かしてみると

$ ruby script/spec -c spec/models/item_spec.rb
F

1)
'Item should be valid' FAILED
expected valid? to return true, got false
./spec/models/item_spec.rb:9:
script/spec:4:

Finished in 0.322841 seconds

1 example, 1 failure

おお、ちゃんと動いた。

理由は不明。

動かなかった方はRails 1.2.6で動いた方はRails 2.0.3なんだけどその違いなんだろうか？
とか思ったが、RSpecのバージョンを1.0.8とかにしてもやっぱりエラーになったので、バージョンとかではなく動かなかった方がなんかおかしいっぽいな。
いろいろプラグインやライブラリを入れているせいだろうか・・・

とりあえず使えるようになったので新しく小さなアプリをRSpec使いながら作ってみようかな。

前半コードを交えていろいろ書いてあるけど、普段からテストを普通に書いてるなら「rcov でテストカバレッジを調べる」の節から読んだらいいと思う。

以下のコマンドでrcovをgemからインストールして

sudo gem install rcov

以下のコマンドで実行。

rcov -x /usr/local/lib/ruby --rails test/**/*_test.rb

「-x /usr/local/lib/ruby」で自分が作ったのではないgem等のテストを無視（パス指定が大雑把かもしれん）、「–rails」でRailsの余計なファイルを無視してくれるということだ。

これでさくっとテストのカバレッジを示したHTMLが出来上がる。
実に簡単で、見て面白い。

アプリを作ってるときにテスト書くのをサボると後でテストを書くというのはけっこうモチベーション的にしんどいものがあるが、これを使いながらだったら書けそうだ。

ちなみにカバレッジによってテストされてないコード箇所は分かるが、適切なテストが書かれているかが保証されるわけではないし、そもそも必要なコードが書かれているかということも教えてくれないので過信は禁物。
カバレッジが100%でもバグはあり得る。

とはいえ、テストの品質と作成効率を上げるのにかなり役立つツールであることは間違いない。