コメント
0件
👏 最初のコメントを書いて作者に喜んでもらおう!
ある日仕事の帰り道で・・・
エンジ
エンジ
エンジ
エンジ
エンジ
テス
テス
エンジ
エンジ
エンジ
テス
ある日、道を歩いていると・・・
テス
テス
テス
テス
テス
ガラガラ・・・
テス
テス
おばちゃん
おばちゃん
テス
テス
テス
テス
テス
おばちゃん
テス
テス
おばちゃん
おばちゃん
おばちゃん
テス
テス
おばちゃん
テス
テス
テス
テス
テス
おばちゃん
それからテスの問いかけはラーメンがくるまで続いた
テス
テス
テス
テス
テス
テス
テス
テス
エンジ
エンジ
エンジ
エンジ
テス
テス
エンジ
3日後、ラーメン屋にて・・・
テス
テス
おばちゃん
テス
テス
テス
おばちゃん
エンジ
エンジ
エンジ
テス
テス
テス
テス
テス
テス
テス
テス
エンジ
エンジ
エンジ
テス
おばちゃん
おばちゃん
おばちゃん
おばちゃん
ドン!!!
テス
テス
テス
テス
テス
テス
エンジ
おばちゃん
テス
テス
テス
エンジ
エンジ
テス
テス
テス
エンジ
エンジ
そう言い捨て、2人は出ていく
おばちゃん
おばちゃん
帰り道にて
エンジ
テス
テス
テス
エンジ
エンジ
エンジ
エンジ
エンジ
エンジ
エンジ
エンジ
エンジ
エンジ
テス
テス
エンジ
そして2人は何とも言えない雰囲気で帰路についた・・・
END
解説
ユニットテストにおいて、実装の詳細にまで検査を入れてしまうと 少しリファクタリングをした場合でもテストコードの修正が必要になる 「もろい」テストになってしまいます。
同様の理由からプライベートメソッドに対してテストを書くことは 実装の詳細に対してテストを書くことになるため 「もろい」テストになりがちです。
今回テスくんは実装の詳細にこだわってしまっていたので 「うまいラーメン」ということことに飽き足らず 詳細部分まで一致しないと気がすまない状態になっていたのです。
実装の詳細と密なテストコードは今後運用していくにあたって 「すぐに壊れる」ため、本番コードの変更やリファクタリングを億劫にさせる 「負債」となってしまいます。
もしくは、そのような「すぐに壊れる」テストコードは メンテナンスされることがなくなり 「このテストはいつも失敗するから無視して」といったような テストコードの存在意義をなくしてしまう場合にも繋がります。 そして割れ窓理論的にメンテナンスされないテストコードが 増えていってしまうのです。
このことから、良いテストコードを書くためには「振る舞い」に着目し 外部から観測できる事柄は何なのか?という点について検証を行なうことで リファクタリングをしても壊れない良いテストが生まれるのです。