unit-testing - TDD で単体テストをどのように編成しますか?

Question

私は TDD を行っていますが、単体テストの編成はかなり緩いものでした。私は、次のストーリーまたは機能のチャンクを表すファイルから始めて、それを機能させるためのすべての単体テストを作成する傾向があります。

もちろん、新しいクラスを導入する場合は、通常、そのクラス用に個別の単体テスト モジュールまたはファイルを作成しますが、テスト自体をより高いレベルの構造に編成することはしません。その結果、私はコードを速く書くことができ、実際のプログラムはかなり適切に構造化されていると思いますが、単体テスト自体は「乱雑」です。特に、それらの構造は発生過程の系統発生を再現する傾向があります。ときどき、コードの怠惰をテストの怠惰と交換しているように自分自身を見ていることがあります。

これはどれほど大きな問題ですか？単体テストを継続的にリファクタリングおよび再編成して、全体的な構造を改善しようとしているのは誰ですか? これに関するヒントはありますか？テストの全体的な構造はどのように見えるべきか。

（ここで尋ねた「関数ごとのアサーションの数」の質問はあまりしていないことに注意してください：関数/メソッドごとにいくつのユニットテストを書く必要がありますか？私は全体像について話している。）

Answer 1

テストを 2 つのセットに分けます。

• 機能テスト
• 単体テスト

機能テストはユーザーごとのストーリーです。単体テストはクラスごとです。前者は実際にストーリーをサポートしていることを確認し、後者は機能を実行して文書化します。

機能テスト用のディレクトリ (パッケージ) が 1 つあります。単体テストは、それらが実行する機能と密接に結びついている必要があります (したがって、それらは散らばっています)。コードを移動してリファクタリングするときに、それらを移動してリファクタリングします。

Answer 2

それほど重要でない部分は、テストの編成です。

まず、テスト対象のクラスに関連するクラスにテストを配置することから始めます。したがって、com.jeffreyfredrick.Foo にはテスト com.jeffreyfredrick.FooTest があります。しかし、これらのクラスのサブセットで別のセットアップが必要な場合は、それらを独自のテスト クラスに移動します。テストを別のソース ディレクトリに配置しますが、同じプロジェクトに保持します。

より重要な部分は、テストのリファクタリングです。

はい、私は自分のテストをリファクタリングしようとしています。目標は、宣言的で読みやすいままで重複を取り除くことです。これは、テスト クラス内でもテスト クラス間でも同じです。テスト クラス内には、テスト フェイク (モックまたはスタブ) を作成するためのパラメーター化されたメソッドがある場合があります。私のテスト フェイクは通常、テスト クラス内の内部クラスですが、必要があれば、テスト全体で再利用するためにそれらを引き出します。適切と思われる場合は、一般的なメソッドを使用して TestUtil クラスも作成します。

テストをリファクタリングすることは、大規模なプロジェクトで単体テストを長期的に成功させるために重要だと思います。テストが脆弱すぎる、または変更が妨げられていると不平を言っている人を聞いたことがありますか? クラスの動作を変更するということは、テストに数十または数百もの変更を加えることを意味するという立場にはなりたくありません。コードと同様に、リファクタリングとテストのクリーンな維持によってこれを実現します。

テストはコードです。

Answer 3

ソフトウェアのすべてのクラスについて、単体テストクラスを維持しています。単体テストクラスは、テストされるクラスと同じパッケージ階層に従います。

単体テストコードは別のプロジェクトに保管しています。また、テストコードを同じプロジェクトの「test」という別のソースディレクトリに保存することを好む人もいます。あなたはあなたにとって快適であると感じるものなら何でも従うことができます。

Answer 4

アプリケーション内のクラスごとに単体テスト クラスを作成し、テスト クラスをテスト対象のクラスと同じパッケージ構造に編成します。

各テストクラスの中には、あまり組織構造がありません。テスト対象のクラスのパブリック メソッドごとに少数のメソッドしかないので、探しているものを見つけるのに問題はありませんでした。

Answer 5

私は単体テストを単独のプロジェクトとして見ようとしています。他のプロジェクトと同様に、組織は何らかの内部ロジックに従う必要があります。ただし、具体的または正式に定義する必要はありません。プロジェクトを適切に整理してクリーンに保つ限り、使い慣れたものであれば何でも問題ありません。

そのため、単体テストでは通常、メイン プロジェクトのコード構造に従うか、(場合によっては) 代わりに機能領域に焦点を当てます。

それらを 1 つのヒープに残すことは、ごちゃごちゃして維持するのが難しいと想像するかもしれません。