Question

目前，我正按分组（项目）拆分所有测试。因此，如果我有12个项目，我将为单元测试创建另外1个项目，其中12个类将测试我的所有包。

你是按照同样的方式做的，还是按班级进行1次测试？你如何组织所有考试？

Answer 1

在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

Answer 2

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

Answer 3

和Pokus一样，我的测试与要测试的类在同一个程序集中，所以我可以测试内部和私有。

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

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

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

Answer 4

我们有这样的组织（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

unit-test 和 integration-test 只是测试运行者， test / data 包含集成使用的数据文件tests和 test / tmp 保存由相同测试创建的临时文件，并为每个测试套件清除。

Answer 5

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

作为一个例子（不是我的真实包名）：

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

Answer 6

我的课程中有我的测试课程。这样我可以测试内部的东西。我将“测试”后缀添加到类名中。示例：MyClass.cs将是MyClassTest.cs

Answer 7

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

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

Answer 8

我将它们保存在整个产品的单独包装中。我不喜欢用单元测试代码弄乱生产代码。

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

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

Answer 9

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

例如：

Company.Product.Feature
ClassnameAlpha
ClassnameBeta
ClassnameDelta

Company.Product.Feature.UnitTests
ClassnameAlphaTests
ClassnameBetaTests
ClassnameDeltaTests

我接受了xando做得更多的事情。我没有使用默认的调试/发布配置，而是为Team Foundation Server中用于构建配置的每个分支配置了一个配置。所以，我有开发，集成和生产。在没有考虑到麻木无聊的细节的情况下，单元测试是为开发和集成配置而构建的。它们包含在Production分支中，但不是使用构建编译的。包含它们的原因是当我们必须从生产分支（例如，修补程序）时，可以使用修改后的代码运行，修改和反向集成单元测试。

我们目前只有一小部分团队使用此功能，因为我们正在从旧产品和版本控制系统迁移，但到目前为止它运作良好。到目前为止，它的单元测试方面效果特别好。

Answer 10

我喜欢让他们接近他们支持的代码，通常是在一个单独的子目录中。这样我就可以让他们使用代码进行编译，这使得它们可见 - 当只有少数组件进行单元测试时，遗留项目非常重要。

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

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

拇指规则是让单元测试易于查找，易于编译和易于运行，这样他们就不会陷入困境。

Answer 11

我按照测试类别组织我的测试。如果我的所有单元测试文件都在1目录中。所有集成在1个目录中。我在另一个中进行了所有持久性测试。所有文件夹都有许多文件用于测试每个类似的东西。

UnitTest如何组织测试文件？

11 个答案: