我一直在做一些使用TDD开发测试;即先写我的测试。
我一直被用来编写像这样的测试，使用这种命名约定。
MethodName_DoesWhat_WhenTheseConditions
这些单元测试工作的伟大，因为我知道的方法名是什么，但这样做TDD我不知道的方法名。比如我有状态的用户故事
"As a user, I can return the total number of records in the database"
现在只是考虑看看这个，我知道马上我将有许多方法，层。
但我不知道这些方法的名称在TDD现在，所以它是有意义的尝试和前缀测试的名字呢？没有人有任何建议吗？
也曾经我写我的测试，我的方法/类和一切工作是否有意义创造更多的“单元测试”来测试我的东西通过TDD没有阶级？
通过下面的“外到内”的发展方针，你会发现/发展你的TDD单元测试的名称作为开发过程的一部分（见这个答案here）
例如把你的用户故事（我稍加修正它）：
As a user
I want to know the total number of records in the database
So that I can report back to the business owner
在开发这个故事，你会分解成若干场景如
Given a user logs in
When they request the total number of records
Then they should be presented with the result
在这个阶段，你还是不知道你需要什么单元测试。然而，使用“外到内”的开发方式，你现在想恢复到TDD技术来实现必要的功能。
例如，你会使用你的正常TDD方式未来实现登录设施。因此，你可能有一个名为测试方法：
WhenSubmitValidCredentials_ShouldBeAuthorised
您也可以“假，直到你把它”使用这种方法，即你可以嘲笑某些依赖（如授权机制），使您可以专注于实施方案的主要特点。
所以下面这种方法，你会逐步开发所有的你的用户故事，而创建精确的单元测试，以满足场景所需的功能。
考虑到用户的故事，我的测试名称会是这样的：
而测试类会是这样的DatabaseRecordCounterTest。
有许多方法来测试命名，你提到的是其中之一的一个。用方法名加前缀是好的（并适用于最大多数情况下），但是当你的单元测试通过跨越多种方法（即common add-remove or add-search combinations），你可能会遇到一些小问题。
随着TDD，你应该与用户故事开始（因为你现在做的），并依此命名测试。只有这样，你去实现。随着TDD，你的方法名称将通过测试来驱动。
也曾经我写我的测试，我的方法/类和一切工作是否有意义创造更多的“单元测试”来测试我的东西通过TDD没有阶级？
不应该有你不通过TDD做一件事。这是整点 - 你开你的设计和实现通过测试。你不写的代码，不会从失败测试起源单行。
我喜欢用两种方法是我从Phil Haack和Erik Dietrich偷走
基本上有是定义被测类的基类，那么继承被它们将测试行为的名字命名的类。测试然后用冗长的名字加入。
public class TestClassUnderTest
{
public ClassUnderTest Target { get; set; }
[SetUp]
public void before_each_test()
{
Target = new ClassUnderTest();
}
// Now each behavior has its own class with the system under test available through the Target property
public class ThisMethod : TestClassUnderTest
{
[Test]
[ExpectedException(typeof(Exception))]
public void throws_if_null_is_passed()
{
Assert.IsTrue(false); // make it fail at first
}
[Test]
public void returns_true_if_string_is_empty()
{
Assert.IsTrue(false); // make it fail at first
}
}
public class ThatMethod : TestClassUnderTest
{
[Test]
public void returns_argument_concatenated_with_timestamp()
{
Assert.IsTrue(false); // make it fail at first
}
}
}
有了这个系统测试类的名称（在这个例子中ThisMethod和ThatMethod）可以抽象成你正在测试针对直到命名是有意义的行为方面。您可以通过后所需的行为将其命名为开始，然后或者如果适用重构行为名称为函数名，或者（如果该行为跨越多个方法，例如例如：InstanciatioAndInitialization与测试initialization_must_be_called_before_any_other_calls_to_the_system）完善它。一个不错的奖金是所有测试在逻辑上划分成相同的情况下，在你测试UI这使得很好。