絶対に笑ってはいけないRSpecの現場24時
こんにちは、SHIMADAです。 今日は現場の泥臭いRSpec話を書きます。 新しいフィーチャーを追加するとき、specがなかなか通らない、実装が思い通りに進まない、ということがありますよね。 そんなとき、自分の書いたコードが実際にはどう動いているのか確かめる方法が欲しいです。 一番簡単で広く使われているのはデバッグプリントという手法です。 コードの中に p 変数名 と書くと、specの実行途中にその変数の中身がどうなっているか確認できます。 ここで問題になるのが、specがたくさん書いてあるとデバッグプリントが一杯出てきて肝心の調べたいケースが埋もれてしまうという点です。 ちなみに今携わっているプロジェクトのspecを見てみると、examplesの数が1,000を超えてました。 これが一般的な水準で多いのか少ないのか分かりませんが、ここまできてしまうとデバッグプリントがどかどかっと表
えっ、私のテストカバレッジ、低すぎ…？ - いま作ってます。
まとめ テストの「カバレッジ」には、C0, C1, C2の3レベルが存在する 一般的なカバレッジ測定ツールはC0しか測定できない C0だろうがC2だろうが、カバレッジは目安にしかならない とはいえ、他に目安になる物は何もないので、見ないよりは見た方がいい 序 しばらく前のShibuya.js*1が面白そうだったので指をくわえながらIRCで後輩に一席ぶった「テストカバレッジの罠」について書いておくよ。 FizzBuzzのテスト 以下のようなコードを考えよう*2。 <?php function fizzbuzz($i){ $return = ''; if( $i % 3 === 0 ) $return .= 'Fizz'; if( $i % 5 === 0 ) $return .= 'Buzz'; if( $i % 3 !== 0 && $i % 5 !== 0 ) $return = $i;
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
