なぜ大抵の単体テストがクソなのか？

James O Coplien のWhy Most Unit Testing is wasteより

最後のまとめを和訳

ツッコミ大歓迎。

Keep regression tests around for up to a year — but most of those will be 
system-level tests rather than unit tests. 

回帰テストを一年間続けよう。ただしテストのほとんどは単体テストではなくシステムテストになる

Keep unit tests that test key algorithms for which there is a broad, formal, 
independent oracle of correctness, and for which there is ascribable business 
value. 

ビジネス価値をもたらすアルゴリズムの単体テストを維持しよう

Except for the preceding case, if X has business value and you can text X 
with either a system test or a unit test, use a system test — context is 
everything. 

あるビジネス価値を保証するのに単体テストとシステムテストどちらも選べるならシステムテストを選ぼう

Design a test with more care than you design the code. 

テストの設計はコードの設計より念入りに行おう

Turn most unit tests into assertions. 

単体テストは(契約としての)アサーションに置き換えよう

Throw away tests that haven’t failed in a year. 

一年間失敗しなかった単体テストは捨てよう

Testing can’t replace good development: a high test failure rate suggests 
you should shorten development intervals, perhaps radically, and make 
sure your architecture and design regimens have teeth 

テストは良い開発の代わりにはならない

If you find that individual functions being tested are trivial, double-check
 the way you incentivize developers’ performance. Rewarding coverage or
 other meaningless metrics can lead to rapid architecture decay. 

カバレッジやらの意味の無いメトリックスにこだわるとアーキテクチャはおかしくなる

Be humble about what tests can achieve. Tests don’t improve quality: 
developers do. 

テストの出来ることを過信しない。テストで品質は向上しない、開発者だけがそれをなす

免責

これは個人の翻訳です。内容、正確性を保証するものではありません。

Jim Coplien情報

• DCI
• ジム・コプリエン - James O. Coplien(Jim Coplien)
• アレグザンダー祭りにて、James.O.Coplienが語るアジャイルとスクラムの源流とは
• Jim Coplien - Wikipedia, the free encyclopedia

著書