UnitTest你如何组织你的测试文件？

目前，我正在通过包（项目）拆分所有测试。因此，如果我有12个项目，我将为12个课程创建1个单元测试项目，这将测试我的所有包。UnitTest你如何组织你的测试文件？

你是否按照同样的方式做了测试，还是你有1个班的测试班？你如何组织你所有的测试？

2008-11-19 Patrick Desjardins

像Pokus我的测试是在相同的程序集作为要测试的类，所以我可以测试内部和私有。

在C＃中有Debug和Release版本，我用编译器指令UNITTEST添加了另一个名为UnitTest。然后，我可以在测试类的顶部添加指令（#if UNITTEST），以便在编译Debug或Release时不会编译测试，但是当我编译UnitTest时它们是。

我添加了一个名为Tests的文件夹，其中包含我的测试类。 Class1.cs有一个测试类Tests \ Class1UnitTest.cs。

也许更好的方法，但这对我有用。

来源

2008-11-19 13:47:58 xando

我们又组织这样的（C++）：

package/Class.cpp 
package/Class.hpp 
package/test/ClassUnitTest.cpp 
package/test/ClassIntegrationTest.cpp 
test/unit-test/main.cpp 
test/integration-test/main.cpp 
test/data 
test/tmp

凡单元测试和集成测试只是在测试运行，测试/数据持有所使用的数据文件通过集成测试和test/tmp保存由相同测试创建的临时文件，并针对每个测试套件进行清除。

来源

2008-11-19 13:21:09

因为我倾向于做TDD，所以我为每个类都有一个测试类，并将这些测试类分组为一个直接测试类，以便将测试项目与实际项目进行匹配。根据解决方案的大小，测试项目要么存在于相同的解决方案中（如果很小），要么分解成单独的解决方案（如果更大）

来源

2008-11-19 13:23:06

我将我的单元测试保存在他们测试的项目中的包中。通过这种方式，所有测试都通过应用程序代码检出版本控制。单元测试目录基本上是源目录的镜像，因此两者之间的包结构是相同的。

为例（不是我真正的包名）：

src.com.app 
src.com.app.model 
src.com.app.view 
src.com.app.controller 

tests.com.app 
tests.com.app.model 
tests.com.app.view 
tests.com.app.controller

来源

2008-11-19 13:28:14

在Java/Maven的设置：

project/src/main/java/Package/Class.java 
project/src/test/java/Package/ClassTest.java 
project/src/main/resources/Package/resource.properties 
project/src/test/resources/Package/test_resource.properties

来源

2008-11-19 13:29:14 boutta

Maven非常适合帮助促进与项目结构的一致性，包括如何构建单元测试。 – rich 2008-11-19 13:45:05

我倾向于使用相同目录中的资源来构建项目结构化的项目/ src /包和项目/测试用例/包，但我从Eclipse来到Maven而不是其他方式。无论如何，Maven允许我将源代码目录覆盖到我的结构中。 – 2008-11-20 06:06:39

我有我的测试类在我的项目所在班级的。这样我可以测试内部的东西。我将“Test”后缀添加到类名称中。例如：MyClass.cs将MyClassTest.cs

来源

2008-11-19 13:35:37 Pokus

我们做一对一的测试程序集（C＃）。对于解决方案中的每个组件，我们都有相应的测试项目。每个项目都对相应项目中的每个班级进行测试。

例如：

Company.Product。特征
ClassnameAlpha
ClassnameBeta
ClassnameDelta

Company.Product.Feature.UnitTests
ClassnameAlphaTests
ClassnameBetaTests
ClassnameDeltaTests

我把xando做得更进一步。我没有使用默认的调试/发布配置，而是针对我们用于Team Foundation Server中的构建配置的每个分支进行配置。所以，我有开发，集成和生产。没有进入思维麻木无聊的细节，单元测试是为开发和集成配置而构建的。它们包含在生产分支中，但未与生成一起编译。它们包含的原因是因为当我们必须分支生产（例如修补程序）时，可以运行，修改单元测试，并与修改的代码进行反向集成。

由于我们正在从传统产品和版本控制系统迁移过程中，目前我们只有一小部分使用此权利，但到目前为止效果良好。到目前为止，它的单元测试方面效果特别好。

来源

2008-11-19 14:07:38

我喜欢让我的src和测试存在于同一个包中。所以我组织我的如下：

src/com/company/package/Class.java 
testsrc/com/company/package/ClassTest.java

来源

2008-11-19 14:32:21

我把它们放在整个产品的单独包装中。我不喜欢用单元测试代码来混淆生产代码。

 
Company/Product/Package1 
Company/Product/PackageN 
Company/Product/UnitTest/Package1/Class/Method1Fixture.cs 
Company/Product/UnitTest/Package1/Class/MethodNFixture.cs 
Company/Product/UnitTest/PackageN/Class/Method1Fixture.cs 
Company/Product/UnitTest/PackageN/Class/MethodNFixture.cs

我所有的方法都被宣布为公共虚拟，我也使用了很多嘲讽。当然，这主要来自于我单元测试的包通常是业务逻辑和数据层，所以他们很少有任何真正的内部方法。但我确实有一些有“内部”方法的项目。对于那些，如果他们是内部公司代码，那么使用公开所有方法不是问题。我相信如果你不想公开所有的方法，你可以使用强命名的程序集并进行设置，以便单元测试程序集可以访问内部方法。最后，我有一个单元测试组件，它将包含整个项目的所有测试装置。

来源

2008-11-19 17:39:12 Adrian

我喜欢让它们保持接近它们支持的代码，通常在一个单独的子目录中。这样，我可以让它们与代码一起编译，这使得它们可见 - 当仅有少数组件进行单元测试时，这一点很重要。

.../component/src/ 
       /include/ 
       /doc/ 
       /bin/ 
       /test/

我们通常每个二进制文件都有一个套件，但这有例外。我们可以用简单的命令在任何目录下运行所有的测试。

经验法则是让单元测试很容易找到，易于编译和易于运行，使他们不会陷入困境。

来源

2008-11-27 08:03:48 philant

我有我的测试分类测试组织。如果我所有的单元测试文件都在1个目录中。全部集成在1个目录中。我有其他所有的持久性测试。所有文件夹都有许多文件供每个类似的测试项目使用。

来源

2008-11-27 21:10:22

UnitTest你如何组织你的测试文件？

回答

相关问题