UnitTest how do you organise your testing files?

Question

Currently, I am splitting all my tests by package (projects). So if I have 12 projects, I will create 1 more project for Unit Test with 12 classes that will test all my package.

Do you do the same way or do you have 1 testing class by class? How do you organize all your test?

Answer 1

We have it organized like this (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

Where unit-test and integration-test are just the test runners, test/data holds data files that are used by the integration tests and test/tmp holds temporary files created by the same tests and is cleared for each test suite.

Answer 2

Because I tend to do TDD, I have a test class for every class, and group those test classes into a direct one for one matching of test project to real project. Depending on the size of the solution, the test projects either exist in the same solution (if small), or get broken out into separate solutions (if larger)

Answer 3

I keep my unit tests in a package within the project they test. This way all of the tests get checked out of version control with the application code. The unit test directory is basically a mirror of the source directory, so that the package structure is identical between the two.

As an example (not my real package names):

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 4

In a Java/Maven setting:

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 5

I have my test class in my project where the class are. This way I can test Internal stuff. I add "Test" postfix to the class name. Example : MyClass.cs will be MyClassTest.cs

Answer 6

Like Pokus my tests are in the same assembly as the classes to test so I can test internals and privates.

In C# you have Debug and Release builds, I add another called UnitTest with a compiler directive UNITTEST. I can then add the directive(#if UNITTEST) at the top of the test class, so that when I compile Debug or Release the tests are not compiled in, but when I compile UnitTest they are.

I add a folder called Tests that contain my test classes. Class1.cs has a test class Tests\Class1UnitTest.cs.

Maybe better ways, but this works for me.

Answer 7

We do one-to-one test assemblies (C#). For each assembly in a solution, we have a corresponding test project. Each project has a test for each class in the corresponding project.

For example:

Company.Product.Feature
  ClassnameAlpha
  ClassnameBeta
  ClassnameDelta

Company.Product.Feature.UnitTests
  ClassnameAlphaTests
  ClassnameBetaTests
  ClassnameDeltaTests

I take what xando does a bit further. Instead of using the default Debug/Release configurations, I have a configuration for each of the branches that we use for build configurations in Team Foundation Server. So, I have Development, Integration, and Production. Without getting into mind-numbingly boring specifics, the unit tests are built for the Development and Integration configurations. They are included in the Production branch, but not compiled with the build. The reason that they are included is for when we have to branch off of Production (a hotfix, for example) the unit tests can be ran, modified, and reverse-integrated with the modified code.

We currently only have a small subset of the team using this right now, as we are in the process of migrating from a legacy product and version control system, but so far it works well. The unit testing aspect of it works especially well, so far.

Answer 8

I like to have my src and tests exist in the same package. So I organise mine as follows:

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

Answer 9

I keep them in a separate package for the entire product. I do not like to clutter up the production code with unit test code.

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

All my methods are declared public virtual, I use mocking a lot as well. Granted, this mostly comes from the fact that typically the packages I am unit testing are the business logic and data layers, so they rarely have any true internal methods. But I do have some projects that have "internal" methods. For those, if they are internal company code, then using public for all methods is not an issue. I believe if you don't want to make all the methods public, you can use strongly named assemblies and set them up so that the unit test assembly can access the internal methods. In then end, I have a single unit test assembly that will contain all the test fixtures for the entire project.

Answer 10

I like to keep them close to the code they support, generally in a separate sub directory. That way I can have them compile with the code, which makes them visible - this is important is legacy projects when only a few of the components have unit tests.

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

We generally have one suite per binary, but this has exceptions. We can run all the tests under any directory with a simple command.

The rule of thumbs is to have unit tests easy to find, easy to compile and easy to run so that they do not get in one's way.

Answer 11

I have my test organized by categorie of test. If have all my unit test file in 1 directory. All integration in 1 directory. I have all persistence test in an other. All folders have many file for each similar thing to test.