私の意見では、単体テストケース自体がコードのドキュメントとして機能します。私の会社では、単体テストケースの上に詳細なjava docコメントを書いてほしいと思っています。そうする必要がありますか？そんなコメントはありますか？
回答:
私がやっていることはJAVADOCコメントです：
どのクラスがユニットテストされているかを示すクラス（そのサブジェクトのベストプラクティスでは、テストケースの名前はクラスの名前+ "Test"または+ "TestCase"であることが推奨されているため、明らかであるはずです）。これは、{@ link XXXClass} JAVADOCコメントを使用して行われます
テストされるメソッドを示すメソッド（{@link XXXClass＃method1}）。すべてのパスを適切にテストするために、クラスの1つのメソッドに対して複数のテストメソッドが必要になる場合があります。それが起こったら、私は内部でテストしているパスを示す追加の行を1つ書き込みます（ただし、1行の規則から逸脱することはありません）。
それを除いて、他のコメントはありません。他の場所で彼らの注意を引くには、Coberturaのようなものを使用して、かなりのコードカバレッジグラフィックを生成し、それらをそのように幸せにすることができます。
追加の注記：単体テストケースを参照しています。統合テストケースについて話している場合、何が起こっているのかを説明するために1行または2行追加する必要があります。
コードのドキュメント要件は、この質問に対する回答でかなり完全にカバーされています。上司は、コードについてナレーション付きの1行ずつの英語の説明を望んでいます。
そこに表示される答えの要約として、「状況によって異なります」。それが妥当である（そして奨励されている）場合と、それがあなたの時間の浪費である場合があります。
Javadocコメントは、個別の参照ドキュメントに抽出してフォーマットできますが、単体テストはできません。また、言葉で書くものは実際のコードとは異なる場合があり、通常は実際に予想される動作を言葉で説明していることに注意してください。バグを見つける方法の1つは、ドキュメントと実際のコードを比較することです。一致しない場合、それはバグです（どちらか、場合によっては両方）。
単体テストはテスト用であり、ドキュメントではありません。ドキュメントとして単体テストを使用するのは誤りであり、実行すべきではありません。