2

バックグラウンド

私はJava、slick2d、その他のフレームワークを使用して小さなゲームを書いています。Slick2dを使用すると、単体テストを簡単に作成できませんが、それを回避することはできません。プロジェクトの目標の1つは、テストカバレッジを確保することでしたが、...

問題

ええと...私は15のテストを含む200行のテストケースを作成しましたが、すべて1つのメソッドのみを使用するクラス用です。

無効な引数、無効な引数の組み合わせ、メソッド呼び出しの交換など、考えられるすべてのことをテストしました。すべてをテストできるわけではなく、ライブラリ（Java API、slick2d API、logback APIなど）からコードをテストする必要がないことはわかっていますが、その場合でも、テストに夢中になる可能性があります。作成するメソッドごとに15個のテストを作成すると、完了できないと思います。それで...

質問

優れたTDDは、テストの作成時にどこに線を引きますか？正確に何をテストする必要があり、何を安全に無視できますか？

OBS：不思議に思う方のために、私が15のテストを作成した単一メソッドクラスは、いくつかの文字列を配列にロードし、そのメソッドは、引数として行とファイルを指定して文字列を取得します。

OBS2：私はユニットテストにまったく懐疑的ではありません。私は実際にそれらをプロジェクトに（APIで許可されている場合はいつでも）ゼロから組み込みたいと思っています。私もプロジェクトを終わらせたいだけで、一日中テストを書いて死ぬことはありません。

4

4 に答える 4

2

次の本をお勧めします：http ：//www.amazon.com/dp/0321146530/？tag = stackoverfl08-20 from Amazon
本の推奨事項のほかに、テストを設計するとき、最初は多くの作業があります。しかし、ある時点で、新しいコードごとに、ほとんどのテストロジックがすでに配置されています。また、侵入防止
に も焦点を当てることをお勧めします（SQLインジェクション、バッファーovfなどをテストするコード） コードを書いた人がテストを書いた人である場合、覚えておくべきもう1つのポイントはそれを分解しようとする他の誰かが欲しいかもしれません...すべてではなく、少なくともその一部のために。

于 2012-09-11T03:17:44.980 に答える
1

私は主にパブリックメソッドに対してのみ単体テストを作成します。メソッドが正しく機能していると思ったら、メソッドのテストの記述をやめ、バグを見つけた場合にのみメソッドのテストを追加します。

于 2012-09-11T02:48:32.627 に答える
1

TDDについて話している場合は、テストが設計を推進し、最終的なAPIがどのようになるかという理由だけで、アプローチは最初にテストであることを忘れないでください。このアプローチを使用すると、新しいテストの作成を停止する場所が少し明確になります。

于 2012-09-11T02:54:33.690 に答える
1

さて、適切なTDDでは、実際に最初に追加したい新機能のテストを作成します。最初は、動作が実際に正しいことを確認するアサーションとともに、目的の内容を完全に実装するまで失敗します。

したがって、新しい機能が必要になったときに、テストを追加するプロセスを続行するだけです。そうすれば、テストはあなたが書いたコードを駆動し、その逆ではありません。

于 2012-09-11T02:56:55.577 に答える