也许你误会了。产品源代码中不应包含测试代码/注释。

但是，在某些公司的测试代码通过源代码管理以与产品代码相同的方式管理，并被检入相同的构建分支。

我不会在代码注释中存储书面测试用例。它太分散了，会使阅读测试用例和源代码本身变得更加困难。此外，许多书面测试用例使用了更丰富的媒介（包括图片、图表等），而这些媒介在评论中没有得到很好的表达。

至于将您的书面测试用例存储在源代码控制系统中，这有时是有道理的。通过这种方式，它们可以很容易地与您的代码一起进行版本控制。

但是考虑一下你的测试用例的读者是谁。他们是否都拥有对您的源代码控制系统的访问权限、许可证等？这是对所有读者有效的机制，还是只对程序员有效？

在我的商店，我们将所有文档（以及大多数其他测试资产）存储在 SharePoint 中。对我们来说，这是整个组织使用的“标准”机制，非常适合我们测试文档的所有读者。

我想知道当我使用 Perl 框架时，在测试代码中是否以这种方式记录了这些案例，以便使用 Doc 系统（如 PerlDoc 或其他东西）提取这些案例。虽然有实际的生产代码？不，我没有看到这一点，因为这意味着您的生产系统的代码膨胀，您的案例作为注释......除非它们在编译之前被剥离。

我还看到 SCCS 在主代码树之外有一个测试文件夹，我见过的几乎大多数开源项目也这样做，所以测试是连接的，但不需要检查和编译。

就我个人而言，我喜欢将我的测试分开，我的测试框架在 SCCS 中有自己的位置，这样它们就可以保持最新状态，并且不依赖于生产版本来更新。它还让我处于一个更安全的环境中，因此如果我的测试框架还不支持它，那么只要支持生产代码的框架得到更新（如 .NET 3.5 到 4.0），就不会发生交叉污染。

有人可能会争辩说，如果测试用例记录在源代码中，则更有可能对其进行更新。然而，根据我的经验，评论往往是过时的。我怀疑测试用例也会过时。

当发现测试用例过时（或丢失）时，谁来更新它：开发人员还是测试人员？根据我的经验，开发人员通常对测试人员对源代码进行任何更改感到不舒服，即使只是对注释进行更改。

在我的组织中，测试用例保存在 Wiki 中。