現在、JPAの問題を調査しています。私はその問題について頭の中で2つの可能な解決策を思いついた。各ソリューションが問題をどのように解決するかを示す一連の単体テストを作成しました。各ソリューションのテスト中に、1つが機能しないことを発見しました。
ここで、その特定のソリューションが機能しない理由を文書化したいと思います。例外を予期するために、現在持っている単体テストを書き直すことができます。ただし、例外は、そのソリューションの根本的な問題の症状にすぎません。そこで、そのソリューションがJPA仕様と矛盾する点を明確に示す新しい単体テストを作成しました。ただし、そのようなソリューションで発生する可能性のある症状のドキュメントとして、これらの他の失敗したテストを保持したいと思います。したがって、それらを無効にして、その特定のテストケースのために無効になっていると言ってjavadocを配置することができます。
テストケースが失敗することは望ましくないことに注意してください。それ以外の場合は、 assumesを使用することもできます。
実際の問題が成功したことを文書化する別のテストが原因で失敗するため、いくつかのテストを実行する必要がないことを文書化する方法は他にありますか？
ソリューションにjunitを使用するように制限されています。
編集：
これまでのコメントと回答に関しては、誰かがそれらを実行したい場合、テストは変更なしで実行可能であるため、私はカテゴリを好みます。私がまだ懸念しているのは、問題の症状を表すテストと実際の原因とのより強い関連性です。これは現在、症状テストから実際の原因テストへのjavadocリンクにすぎません。