源代码中的测试用例

#1 楼

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

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

#2 楼

我不会在代码注释中存储书面的测试用例。它过于分散，会使阅读测试用例和源代码本身更加困难。此外，许多书面测试用例使用的注释无法很好地表达出丰富的媒介（包括图片，图表等）。

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

但是请考虑谁首先是您的测试用例的读者。他们都对您的源代码管理系统具有访问权限，许可证等吗？这是对所有读者还是程序员有效的机制？

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

#3 楼

我想知道是否在用PerlDoc之类的Doc系统等文档中记录了这些情况，当我使用Perl框架时，在测试代码中以这种方式记录了一些情况。虽然具有实际的生产代码？不，我没有看到，因为这意味着您会将案例作为注释而使代码膨胀到生产系统中……除非它们在编译之前就被剥离了。

我也看到了它在哪里SCCS在主代码树旁有一个测试文件夹，我见过的几乎所有开源项目也都这样做，因此测试已连接，但无需检出并编译。

个人而言，我喜欢将测试分开，我的测试框架在SCCS中有自己的位置，因此可以保持最新状态，而不必依赖生产版本进行更新。它还使我处于一个更安全的环境中，因此，如果我的测试框架尚不支持支持生产代码的框架（例如.NET 3.5到4.0），则只要有更新，就不会出现交叉污染。

#4 楼

有人可能会争辩说，如果测试用例记录在源代码中，则更有可能被更新。但是，以我的经验，评论通常是过时的。我怀疑测试用例也会过时。

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

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

#5 楼

我担心这个问题令我感到困惑。

我们有自动回归测试（检查），这是源代码的很大一部分。每次程序员提交代码（连续集成）时都会运行检查。

但是，自动检查并未部署为实时运行-仅将应用程序代码包装在war文件中并释放。 />
这样，如果程序员在编码时无意中更改了应用程序的逻辑，则自动检查将失败。

我个人而言，我不会将测试用例作为代码中的注释-我看不到这样做的好处。

我觉得user246在Wiki中包含测试用例是正确的主意-这可以作为所有测试的窗口（完全可以）级别），程序员和业务分析师都可以阅读（这是正确的user246吗？）

#6 楼

TL; DR答案

是否都考虑过这些最佳实践：



在注释中存储测试用例：绝对不是，它使自动化测试远远超出了



将测试用例存储在与源代码相同的文件中：并非如此，这太让人分心了。


存储测试用例



将测试用例存储在单独的测试存储库中：是的，但仅在过程需要时。


完整答案

首先，在代码中的注释中存储测试用例的想法似乎是最糟糕的了。您不能轻松地使用测试框架来自动化您的测试，您必须做一些魔术来提取测试并运行它们（因此编写它们时得不到IDE的帮助），并且代码充斥着使测试模糊的测试最简单的选择是将测试用例与要测试的生产代码存储在相同的源文件中。但是，如果没有很多预处理器指令或注释，您最终将导致测试代码不必要地膨胀生产代码，并且取决于代码的结构方式，最终可能会意外地向代码用户公开内部实现。 br />
最好的选择是将测试用例与代码分开存储，并构造代码来支持它。如其他答案中所述，它具有许多优点，但也有一些陷阱。幸运的是，通常有很多方法可以绕过它们，而其他方法似乎还没有讨论过。

示例

例如，如果您要对a的某些私人行为进行单元测试，类，取决于语言/环境，您可能有三个选择：


将测试放入要测试的类中。
将测试放入另一个类/源中文件并将要测试的私有方法公开为公开方法（是）。
使用一个测试环境，该环境允许您将测试代码和生产代码分开，但仍然允许测试代码访问生产代码的私有方法。

在Eclipse世界中，可以通过使用片段来实现3。 。在C＃世界中，我们可能会使用部分类。其他语言/环境通常具有类似的功能，只需要找到它即可。

盲目的假设1.或2.是唯一的选择，很可能会导致生产软件software满测试代码或讨厌的类在公共场所清洗脏亚麻的接口。 * 8'）

版本控制

我很难想象除了将测试用例存储为版本控制下的代码（就像生产代码一样）以外，还可以做其他事情。您可能希望测试代码位于不同的存储库中，甚至可能对测试程序员和生产程序员具有不同的访问权限（如果将两者分开），但是了解正在运行的测试版本同样重要知道正在测试哪个版本的代码。

#7 楼

考虑维护测试用例。如果测试用例本身需要更新，并且位于源代码的注释中，则修改测试用例将强制重新构建软件。这是一个坏习惯。仅当更改代码本身时，才应重新构建代码。

在单独的文件中管理测试用例是另一回事。通过源代码管理跟踪测试用例修订，可以在测试用例修订和软件发行版之间进行追溯。

#8 楼

将测试用例连同源代码一起存储在文件中或源代码注释本身中，可能适用于单元测试，其中始终存在与代码单元的一对一映射。但是，当源跨越数百个文件和数百万行代码时，就无法将所有情况与代码块映射到单个文件中，以进行系统集成测试和后续测试阶段。

某种用于测试用例的版本控制系统，但将其与源代码文件本身混合可能不是一个好主意（除单元测试用例外）。

#9 楼

这是Python在模块中的常见做法，非常有意义。

如果您选择自己运行模块，则它将运行自己的测试用例，并提供自己的API实例以及验证其是否有效。

对于较大的代码库，这些确实是纯示例，而不是完整的测试套件。