Kevin William Pangより。
僕はコードカバレッジにはこだわらないほう。
パーセンテージを上げるための行為が蔓延するから。
Code coverage does not tell us what code is working and what code is not. Again, code coverage only tells us what was executed by our unit tests, not what executed correctly. This is an important distinction to make. Just because a line of code is executed by a unit test, does not necessarily mean that that line of code is working as intended.
Is Code Coverage Really All That Useful?
コードがカレッジではどのコードが動作してどのコードが動作しないかしかわからない。
もう一度言うけど、コードカバレッジはユニットテストで実行したことしか教えてくれない。正確に実行したかどうかは教えてくれないんだ。
これは作成のときにきちんと区別しとかないと。コードはユニットテストが実行しただけであって、必ずしも意図した通りにコードが動作したかはわからないんだ。
ここでサンプルコードが出てきて。
double Foo(double a, double b)
{
return a / b;
}
これ適当にユニットテスト1つ作るとカバレッジ100%になるけど0渡すと例外が発生するよ、ってこと。
道路のアナロジーが出てきて、道路作って普通車通したらカバレッジ100%だけど、いざ開通したらトレーラーとかスポーツカーも通るよ、と。あと天候もいろいろな状態があるから、もしテストしようとしたらそういうあらゆる組み合わせを試さないといけないよ、と。
つまりカバレッジの数字の意味のなさを例示してる。
In light of this, the only solid conclusion you can draw from code coverage seems to be what lines of your code have definitely not been tested. The lines that have been tested are still up for grabs it seems unless you are willing to go through each and every possible state the application can be in when executing them. This makes code coverage far less useful as a metric as it only tells you what still needs testing but offers you no help in determining when you are done testing.
Is Code Coverage Really All That Useful?
これでわかることは、カバレッジはテストしていないコードがはっきりわかるだけだということだ。
テストしたコードも実行するときのすべてのパターンを通過させるつもりでもない限り、全然ダメなままだ。
とするとメトリクスとしてのコードカバレッジの有益性は下がってしまう。だってまだテストが必要だってことは教えてくれるけど、どんなテストをすればいいのかってことは何も教えてくれないから。
Unfortunately, there doesn't seem to be a good metric for determining whether a line of code has been thoroughly tested or when a developer is done testing. Perhaps this is a good thing as it keeps us from falling into a false sense of complacency. It simply isn't feasible in even a moderately complex application to test each and every line of code under every possible circumstance. The best case scenario seems to be to test the most common scenarios and reasonable edge cases, then add additional tests as functionality inevitably breaks on those scenarios that you didn't account for. It's an admitedly clumsy system, but it's a realistic one compared to depending on 100% code coverage to weed out all possible bugs. That's not to say that there isn't use in achieving 100% code coverage. Executing the code in one particular state still has value, just not as much as developers seem to give it.
Is Code Coverage Really All That Useful?
不幸なことに、それらはコードを完全にテストするのか開発者がテストするのかを決めるいいメトリクスではないみたいだ。
たぶんこれは間違った自己満足に陥らないようにしてくれる程度のもんなんだ。
完全にテストするなんて、すべてのコードをあらゆる状況においてテストできるようなほどよく複雑であるようなアプリケーションにおいてさえ簡単に実行できるようなことじゃない。
ベストなシナリオはもっともメインとなるシナリオといくつかの例外ケースをテストすることだと思う。それからあなたに責任がないシナリオで、必ず失敗してしまうような機能を追加でテストすることだと思う。
確かに不細工なシステムかもしれないけど、すべてのありえるバグをつぶすために100%のコードカバレッジに依存することと比較すると現実解だ。
これは100%のコードカバレッジを達成することに意味がないと言ってるわけじゃない。
ある状態でコードを実行することにはもちろん価値があるけど、開発者の費用対効果は合わないね。
