我计划为我的团队引入一套编写单元测试的标准，但要包括哪些内容呢？
这两篇文章（单元测试命名最佳实践和单元/集成测试文件系统依赖的最佳实践）已经启发了我一些想法。
应该包括其他领域的内容，例如如何设置测试类以及如何组织它们。例如，如果有一个名为OrderLineProcessor的类，则应有一个名为OrderLineProcessorTest的测试类。如果该类上有一个名为Process()的方法，则应该有一个名为ProcessTest的测试（也许需要多个测试来测试不同状态）。
还有其他需要包括的内容吗？
你的公司是否有单元测试的标准？
编辑：我使用Visual Studio Team System 2008并使用C#.Net开发。
测试不是被视为“测试”，而是作为系统行为的规范（下文称为“规范”）。规范的目的不是验证系统在每种情况下都能正常工作。它们的目的是指定行为并推动系统设计。
规范方法名称应写成完整的英语句子。例如，球的规范可以包括“球是圆的”，“当球撞到地板时，它会弹起”等。
生产类和规范类之间没有强制的1:1关系（为每个生产方法生成一个测试方法是疯狂的）。相反，系统行为与规范之间存在1:1的关系。
你可以在你的标准中加入另一个条目，尽量保持你的单元测试代码规模小。也就是说，实际的测试方法本身。除非你正在进行完整的集成单元测试，否则通常不需要大型单元测试，比如超过100行。如果你有很多设置要到达你的一个测试，我会给你那么多。但是如果你确实这样做了，你应该考虑重构它。
人们还谈论重构他们的代码，确保人们意识到单元测试也是代码。所以重构、重构、重构。
我发现我所见过的用例中最大的问题是人们不倾向于认识到你想要保持你的单元测试轻盈和敏捷。毕竟，你不想为你的测试创建一个庞大的单体。考虑到这一点，如果你有一个你想要测试的方法，你不应该在一个单元测试中测试每个可能的路径。你应该有多个单元测试来考虑方法的每个可能路径。
是的，如果你正确地进行单元测试，你的单元测试代码行数平均应该比你的应用程序多。虽然这听起来像是很多工作，但当不可避免的业务需求变化到来时，它将为你节省很多时间。
确保包含非单元测试内容。请参阅：关于单元测试，不应该测试什么？
包括指南，以便可以清楚地识别集成测试并可从单元测试中单独运行。这很重要，因为如果将单元测试与其他类型的测试混合在一起，则可能会得到一组非常慢的“单元”测试。
有关更多信息，请查看此处：如何改进我的junit测试...特别是第二次更新。
使用全功能集成开发环境的用户会发现，“其中一些”提供了相当详细的支持，以特定模式创建测试。给定这个类：
public class MyService {
public String method1(){
return "";
}
public void method2(){
}
public void method3HasAlongName(){
}
}
public class MyServiceTest {
@Test
public void testMethod1() {
// Add your code here
}
@Test
public void testMethod2() {
// Add your code here
}
@Test
public void testMethod3HasAlongName() {
// Add your code here
}
}
因此，在编写标准之前，您可能需要仔细查看工具支持。
我在单元测试函数名称中使用几乎是简单的英语。这有助于明确定义它们确切的功能：
TEST( TestThatVariableFooDoesNotOverflowWhenCalledRecursively )
{
/* do test */
}
我使用C++，但命名规范可以应用于任何地方。
如果您正在使用Junit（OCunit、SHunit等）工具系列，测试名称已遵循一些规则。
对于我的测试，我使用自定义的doxygen标签，以便将它们的文档收集到特定页面中。