为集成测试选择名称

使用单元测试时，域很小，因此很容易。我使用了Osherove的methodName_conditions_result()方案，发现它很清楚。

但是通过集成测试，我觉得它会叫一个很长的名字，我该用什么代替methodName？如何命名集成测试类？

集成测试名称的真实示例非常受欢迎。我希望答案也能帮助我更好地理解这些测试。

对于单元测试和集成测试，我采取了一些不同的方法。我尝试根据功能尽可能命名它们。然后，当所有测试通过时，您可以看到所有可用功能和不可用功能的列表。

• canRegisterUser
• canHandleInvalidInput
• canRelayDocumentBetweenServers
• canCreateSchema
• canLoginUsingWebService
• canLoginUsingBasicAuth
• canDeleteDocument
• canAddDocument

用这种方式命名测试并不总是实用的，但是在阅读了数百个单元测试和集成测试之后，这可能会很有帮助。包含这些方法的总体类名称也应指示正在测试的功能。这将有助于组织。

我还建议您使用唯一的前缀为bugfix1002漏洞修复命名任何单元测试，以证明该漏洞已得到修复。

这实际上是为帮助单元测试而写的，但是也许您会发现相同的规则（或多或少）适用于集成测试：

退房七个步骤！

我的偏好是无论您叫什么，它实际上都是测试套件名称（我们卡上的灯具名称），您要检查的效果以及需要突出并使错误原因明确的断言消息。如果您发现使用Asherove的命名最简单，那么我将全力支持。但是，也许诀窍是您用使条件，结果和异常有意义的任何东西填充“方法”部分。

我很高兴看到名为“ MakingADeposit”的套件带有一个名为“ AccountDoesntExist”的测试以及一个错误消息：“ Expected NonesuchAccount异常-未收到任何异常”。

或者，如果您不介意我用“ ::”分隔测试套件名称，则可以使用“ AccountHandling :: MakingADeposit_AccountDoesntExist_ThrowsAnException”

该卡还建议，如果您没有好名字，请继续前进，并在出现名字时给您起一个更好的名字（希望在将代码提交给CI之前很好）。

集成测试应该遵循与单元测试类似的规则，因为每个测试都应该测试需求的一个方面，但是要测试整个系统。该类应命名要测试的整体事物，例如“ TpcInputValidation”，并且方法的命名应表达性地反映该测试尝试进行的操作，而不会过于冗长，例如“ shouldRaiseValidationErrorWithBadDates（）”。

这些方法应该测试该功能的一个概念，并且大量的断言可能表示相反。（请参见Robert Martin的“清洁代码：敏捷软件工艺手册”第132页）。

因此，问题在于功能的适当名称对于方法名称而言太长了？我知道开始用类似这样的名称编写测试方法很尴尬，registerAndValidateUnderageUniversityDriverWithCoverageSetA_test()并且可能会破坏长方法名称的编译器规则（PL / SQL仅允许最多30个字符-我不知道Java和C＃是否强加了这样的短名称限制，但即使如果不这样做，那么它会毫无意义地超过某个点，而且实际上很长的方法名称可能仅对由其他生成的代码读取/管理的生成的代码有用。您可以尝试将其缩短为，regValUnderageUnivDrvrWCovrgA_test()但阅读起来真的很恐怖。我曾经不喜欢的一种选择是当时最好的选择是underageUnivDrvr_test_01()然后有一个电子表格，将方法名称映射到要测试的功能的更长的描述。丑陋，但确实有效。您还可以在源文件的功能文档中记录测试的描述，这很有用，因为您可以直接从代码生成测试文档，而不是在电子表格和代码之间来回映射。