ユニットテストメソッドの命名はより意味があるため、ユニットテストメソッドにサマリーを追加する必要がありますか？ユニットテストメソッドで要約が必要です
例：
/// <summary>
/// Check the FormatException should be thrown when a give country data line contains a invalid number.
/// </summary>
[TestMethod]
public void FormatException_Should_Thrown_When_Parse_CountryLine_Containing_InvalidNumber()
{
...
}
長い記述的な名前がXMLコメントよりも重要だと思います。単体テストはAPIの一部ではないので、XMLコメントは必要ありません。例について
：
[TestMethod]
public void FormatException_Should_Thrown_When_Parse_CountryLine_Containing_InvalidNumber()
{
...
}
がより有用である：
///<summary>
/// Exception Should Thrown When Parse CountryLine Containing InvalidNumber
///</summary>
[TestMethod]
public void Test42()
{
...
}
XMLコメントは、APIとフレームワークを文書化するために使用されるべきです。
+1私から。また、単体テストからの文書を見たこともありません。コードがうまく構成されている場合は、自己記述型でなければなりません。 Composedメソッドを使用する場合はこれが典型的です。http://c2.com/ppr/wiki/WikiPagesAboutRefactoring/ComposedMethod.html – RichardOD
には必要ありませんが、あなたが感じる場合は、XMLコメントは、あなたが他のをやっているでしょう（包括的であることをに似ています）ユニットテスト自体の名前の上とを超えて値を追加開発者サービス。
要約が本質的に単体テストメソッド名の直接の複製である場合、これは過度のものだと私は考えています。
私は個人的には、ドキュメントが冗長であることを読むのに十分簡単にテストを行います。私はテストメソッド内でインラインコメントを使用して説明します私は何か特別なやり方をしていますが、何をしているのですか。私はやっています。
あなたの時間を最大限に活用していると思うなら、それをしてください。私はwouldntする。
上記の例では、ソース（javadocなど）からドキュメントを抽出するツールを使用しない限り、必要ではないと言います。
コードはあなたがやっていることを言い、コメントには理由が言われていますが、名前は非常に冗長であるため（誰も入力する必要がないので大丈夫だと思います）そのコメントが何かに貢献しているとは思わないでください。
要約を追加して、メソッド名にエンコードできる情報を追加する必要がある場合は、要約を追加する必要があります。ドキュメンテーションを参照する際に「必要」と言う場合は、「プロジェクトを継承する新しいコーダーに、必要なコンテキスト/詳細/ニュアンスの100％を5年後に伝えること」が必要です。
私は実際には、概要タグの上にDescriptionAttributeを使用する方が好きです。これは、Description属性の値が結果ファイルに表示されるためです。それはあなただけのログファイル
[TestMethod,Description("Ensure feature X doesn't regress Y")]
public void TestFeatureX42() {
..
}
を見ているときに理解するために失敗が容易になりますが、わかりやすいメソッド名を持っている場合、XMLコメントが全く不要です。また、単体テスト方法の必須項目です。
説明的なテスト方法の名前が既に正しいトラックにあります。 （多くのアジャイルとTDDの実務家は、テストメソッドには、たとえばlink textのように「should」を含める必要があると考えています。
MyClass_OnInvalidInput_ShouldThrowFormatException()
しかし、それは単に私の個人的な好みです：
個人的に、私はこのようなメソッド名が好き。
誰かがSkeetの回答が奇妙に聞こえたら、すぐに削除してください。 – Will
@ウィル - はい私もそれに気づいた。 –
@ Will-それは重要ですか？ – RichardOD