目前，我按包（项目）拆分所有的测试。因此，如果我有12个项目，我将创建一个单元测试项目，其中包含12个类来测试我的每个包。
你是否也是这样做，还是每个类都有一个测试类？你是如何组织你的所有测试的呢？
11个回答
7
在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
- boutta
3
Maven非常适合帮助实现项目结构的一致性，包括如何组织单元测试。 - rich
我倾向于将我的项目结构化为project/src/package和project/testcases/package，资源也在同样的目录中，但我是从Eclipse转到Maven的，而不是相反。无论如何，Maven允许我覆盖源目录以适应我的结构。 - Michael Rutherfurd
@Michael：基本上使用Maven可以实现任何功能。但是我们希望在资源和源代码之间有一个清晰的分离（因为我们有很多资源文件）。我并不是说这种方式比其他方式更好，只是我们选择了这种方式。 - boutta
5
像Pokus一样，我的测试与要测试的类在同一个程序集中，因此我可以测试内部和私有方法。
在C#中，你有Debug和Release构建版本，我添加了另一个名为UnitTest的版本，并使用编译器指令UNITTEST。然后我可以在测试类的顶部添加指令(#if UNITTEST)，这样当我编译Debug或Release时，测试不会被编译进去，但是当我编译UnitTest时，它们会被编译进去。
我添加了一个名为Tests的文件夹，其中包含我的测试类。Class1.cs有一个测试类Tests\Class1UnitTest.cs。
也许有更好的方法，但这对我来说有效。
- xando
1
当你更改项目模板或创建自己的模板时，这将变得更加容易，因此UnitTest构建配置已经存在。 - xando
4
因为我倾向于使用TDD，所以对于每个类都有一个测试类，并将这些测试类组合成一个直接匹配测试项目和实际项目的测试项目。根据解决方案的大小，测试项目要么存在于同一解决方案中（如果较小），要么分解成单独的解决方案（如果较大）。
- David Arno
3
我们将其组织如下（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包含被集成测试使用的数据文件，而test/tmp则包含同一测试创建的临时文件，并在每个测试套件结束时清除。
- David Holm
1
我在我的项目中有我的测试类，它们与类在一起。这样我就可以测试内部内容。我将“Test”后缀添加到类名中。例如：MyClass.cs 将成为 MyClassTest.cs。
- Pokus
1
我喜欢将我的源代码和测试存在同一个包中。因此，我将它们组织如下：
src/com/company/package/Class.java
testsrc/com/company/package/ClassTest.java
- Hates_
1
我将它们放在一个单独的包中，用于整个产品。我不喜欢用单元测试代码混淆生产代码。
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 virtual，我也经常使用mocking。当然，这主要是因为我通常测试的包是业务逻辑和数据层，所以它们很少有真正的内部方法。但我确实有一些项目有“internal”方法。对于那些内部公司代码，如果所有方法都使用public不是问题。我认为，如果您不想使所有方法都公开，可以使用强名称程序集，并设置它们，以便单元测试程序集可以访问内部方法。最终，我有一个单元测试程序集，其中包含整个项目的所有测试夹具。
- Adrian
1
我把单元测试放在被测试的项目内的一个包中。这样所有测试都与应用代码一起从版本控制中检出。单元测试目录基本上是源目录的镜像，因此两者之间的包结构是相同的。
以一个示例说明（不是我的真实包名称）：
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
- Bill the Lizard
0
我们进行一对一的测试组装（C#）。 对于解决方案中的每个程序集，我们都有一个相应的测试项目。 每个项目都有与相应项目中的每个类对应的测试。
例如：
Company.Product.Feature
ClassnameAlpha
ClassnameBeta
ClassnameDelta
Company.Product.Feature.UnitTests
ClassnameAlphaTests
ClassnameBetaTests
ClassnameDeltaTests
我对xando所做的事情进行了一些扩展。 我没有使用默认的Debug / Release配置，而是为我们在Team Foundation Server中用于构建配置的每个分支都配置了一个配置文件。 因此，我有开发，集成和生产三个配置。 不想进入令人昏昏欲睡的细节，单元测试是针对开发和集成配置构建的。 它们包含在生产分支中，但不会与构建一起编译。 包括它们的原因是当我们必须从生产环境中分支出来（例如热修复）时，可以运行单元测试，修改并将其与修改后的代码反向集成。
目前，我们只有小部分团队正在使用此功能，因为我们正在从传统产品和版本控制系统迁移，但到目前为止，它运作良好。 尤其是单元测试方面，效果非常好。
- Joseph.Ferris
0
我按测试类别组织我的测试。如果所有单元测试文件都在一个目录中，所有集成在一个目录中。我将所有持久性测试放在另一个目录中。所有文件夹都有许多相似的测试文件。
- Mister Dev
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接