2

職場の上司が、私がしばらく取り組んできた Java プログラムの単体テストを作成するのは良い考えだと判断しました。プログラムはかなり典型的な混乱ですが、巨大ではありません。私は以前に単体テストを使用したり書いたりしたことがありません。この件について読んだすべてのことから、既存のプロジェクトは開始するのに最適な場所ではありません。仕方がないので、いくつか質問させてください。

私の主な質問は次のとおりです。単体テストが何をすべきか、その範囲はどうあるべきか、TDD プロセスでの運用コードの書き方などについて、私は多くのことを読んできました。コードは実際に行くべきです。本番コード クラス自体にテストを記述しますか? それらすべてを別の .java ファイル (または複数のファイル) に入れますか? プロジェクト内の独自のディレクトリに配置しますか? 後者のオプションのいずれかを使用する場合、プライベート オブジェクトとメソッドにアクセスしてそれらをテストするにはどうすればよいでしょうか? これはかなり明白な質問だと思いますが、わかりません。

2 つ目の質問: TDD を使用することについて説得力のある議論をたくさん見てきました。個人的なプロジェクトで試してみたいと思います。私の最初の質問に対する答えは、まったく新しいプロジェクトを開始する場合に当てはまりますか? それとも、新しいプロジェクトとは対照的に、既存のプロジェクトに対して別の方法で単体テストを実装しますか?

4

5 に答える 5

3

テストは本番コードには入りません。別のサブディレクトリに置くことができます。Maven について知っている場合、そのプロジェクトは標準のディレクトリ構造を強制するため、本番コードは src/main/java の下に配置され、プロパティ ファイルは src/main/resources に配置され、テストは src/test/java の下に配置されます。 Java コードで使用されるファイルは、src/test/resources の下にあります。Maven は、ビルドするアーティファクトに src/test 内の何も含まれていないことを確認します。(ant を使用した自家製のビルドでは、多くの場合、これに関して問題が発生します。なぜなら、どこに行くのかを実際に考え、テストとコードを分離しておく努力をしなければならないからです。そうしないと、すべてが一緒になってしまうからです。)

Maven を使用できない場合でも、合意された一般的なモデルに従うためだけに、ディレクトリ構造をコピーする価値があります。

テストでオブジェクトをインスタンス化し、それらのメソッドを呼び出すことで、オブジェクトをテストできるはずです。テストなしで多くのコードを書いた場合、シングルトンなど、テストが難しい方法でコードを書いた可能性があります。より簡単にテストできるようにするために、既存のコードの一部を修正する必要がある場合があります。

于 2013-10-10T20:45:58.307 に答える
2

私はあなたのバグから始めます。バグを修正するときは、バグを示すテストを書きます。バグを修正すると、テストに合格するはずです。ところで、バグの半分がテストにあると予想してください。

非常に些細なことで失敗することはありませんが、失敗するテストを作成すると、テストを持つことの価値がわかります。あらゆる種類の問題は、ユーザーが気付く前に、修正が容易な場合に早期に発見されます。

于 2013-10-10T20:49:49.003 に答える
0

以前に TDD を使用したことがない場合は、このチュートリアルが非常に役立つことがわかります。

Junit チュートリアル

于 2013-10-10T20:51:31.363 に答える
0

プロジェクトのテストを開始するのに遅すぎるということはありません。心配する必要はありません。

Java用のTestNGまたはJUnit 4を学習する必要があります。

テスト用に別の Java ファイルを別のディレクトリに作成する必要があります。たとえば、テスト クラス名は Test で終わる必要があります。 MyClass.java メイン コードの場合、MyClassTest.java テスト クラスを記述します。

質問の他の部分については、以下を参照してください:単体テストとは何ですか? どのように行うのですか?

于 2013-10-10T20:52:43.893 に答える