单元测试是否应该存储在存储库中？

我是一个成长中的程序员，他最终将我存储在GitHub上的库的单元测试付诸实践。

在我看来，我可能会在测试库中包含测试套件，但是当我环顾其他项目时，包含测试似乎是命中注定的。

这是不好的形式吗？是不是用户只对工作代码感兴趣，是否仍将在自己的框架中进行测试？

您绝对应该将测试放入存储库中。我认为测试是代码的一部分，可以极大地帮助其他人理解它（如果写得很好）。此外，当更改或贡献您的代码库时，它们可以帮助其他人。良好的测试可以使您确信所做的更改不会无意间破坏任何内容。

但是，测试代码应与生产代码完全分开。例如，Maven通过将生产和测试代码放入不同的文件夹中来实现这一目标。永远不会出现“此文件是生产文件还是测试代码的一部分”的问题。

我个人不使用自己的代码编写旧库的单元测试。我希望它们能正常工作（至少在使用发行版时，尽管显然会出现错误）。它在集成测试中获得了一些测试覆盖，但这还不够。

如果未在签入的源代码中包含单元测试，则：

• 下载并构建自己的代码副本的人如何验证其按预期的方式工作？编译器和库错误很少见，数据错误（尤其是那些无法使源代码无法编译的错误）更加罕见，但是它们肯定会大量出现，尤其是当您无法确定构建环境的程度时，雇主可以指示使用哪些工具。
• 如果您的源代码本地副本发生了什么，您将如何找回测试？
• 新开发人员将如何验证他们的更改不会破坏现有代码库中的任何内容？

总之，我认为不包括在官方源代码存储库中编写的任何单元测试都是一件很糟糕的事情。

当然，出于以下几个原因，您应该将单元测试放入存储库中：

• 很容易还原到以前的版本
• 其他从事该项目的人也可以访问单元测试
• 有些人认为单元测试是文档的一部分（TDD和BDD）

如果有机会在另一台计算机上运行它们，则一定要包括它们。它们应单独构建，因此用户不必这样做，它们可能具有额外的依赖关系，但应明确包括它们。

我强烈怀疑大多数未在存储库中包含测试的项目根本就没有任何项目。

将测试作为单独的模块可能是有原因的，因此您可以轻松地针对旧代码运行新测试。对于API稳定的库或通过命令行进行黑盒测试将很有用；新测试可能无法使用旧代码编译的编译语言的实用性受到限制。

绝对。此处的额外奖励在于能够跟踪源文件的版本X与测试的版本Y匹配。换句话说，您需要能够返回到先前的版本并提取针对该版本设计的适当测试（如果API发生更改等）。

我刚刚读完“ .Net中的Brownfield应用程序开发”，它为应用程序的结构提供了一些极好的建议，包括源代码控制以及在何处/如何/为什么要包含单元测试（尤其是在持续集成方面） 。如果您是.Net开发人员，则建议使用。