レガシーコードベースのJUnitテストケースを書き始めました。パブリックメソッドの1つに複数のif文があり、条件に基づいて異なるプライベートメソッドが呼び出されています。
1つのテスト方法を書いて、すべての条件をテストすべきですか？または各条件について1つの方法？Junitベストプラクティス：複数のプライベートメソッドを呼び出すパブリックメソッド
if条件ごとに個別のメソッドを記述すると、一貫性が失われませんか？
プライベートメソッドをテストする方法は何ですか？プライベートメソッドロジックはパブリックメソッドよりも複雑になる可能性があります。
テストするシナリオの数に基づいており、テスト対象のメソッドとは関係ありません。
各シナリオに設定するための独自のコードがある場合は、各シナリオに対して1つのテスト方法を取得します。テストをパラメータ化することができれば、1つのテストメソッドを持ち、シナリオごとに異なるデータを渡すことができます。
重要なことは、それぞれの入力の組み合わせに対して、テストを他のテストとは独立して成功または失敗させたいということです。すべてのテストを1つの方法に分割すると、それは起こりません。最初のテストの失敗は、残りのテストの実行を妨げます。
私の見解では、単体テストの単位が小さくなると、通常はより良いテストが行われます。 これは、プライベートメソッドをプライベートパッケージに変更し、プライベートメソッドをパッケージ化してそれぞれのテストを記述することを意味します。
私はNathanに同意します。テストはメソッドではなくシナリオで実行する必要があります。レガシーコードは、プライベートメソッドを直接テストする必要がある方法で記述されることがあります。そして、はい、コードをリファクタリングする必要があります。これは非常に安全なリファクタリングされた方法パッケージプライベートアクセス
作る - しかし、あなたは...最初
オプション1を代わりにテストをリファクタリングたりしたいことができない場合。
オプション2 - ユース反射あなたが本当にコードに触れることができない場合は、静的メソッドを直接
を呼び出すためには、これはあなたができる最善です。私は、コードに触れないという要件に疑問を持っています。コードを改善できない場合は、コーナーで腐敗する必要がありますか？
Groovyでテストを書くかもしれません（プライバシーを尊重しない） 。 –
@NathanHughes優れた提案！ –
できません。これはレガシーコードであり、ロジックの一部を公開することはできません。 –
私はpublicに変更するのではなく、privateパッケージを作成し、テストが同じパッケージに含まれていることを確認します（生産とテストのソースを分けて） – user2088476