Unit testing. File structure

Question

I have a C++ legacy codebase with 10-15 applications, all sharing several components.

While setting up unittests for both shared components and for applications themselves, I was wondering if there are accepted/common file structures for this.

Because my unit tests have several base classes in order to simplify project/customer specific test setups, there are alot of files that are common for all tests.

To me it seems natural here to create a new directory that contains all the test related files, mocks etc -to have it all centralized, and also keep testing related definitions out of the main make files.

On the other hand I see that it is common practice to have the test files reside together with the code files that they test.

Is there a more/less accepted way of doing this?

Answer 1

Out of sight, out of mind; if you keep the test files together with the code files it may be more obvious to the developers that when they update a code file they should update the tests as well.

Answer 2

As you noted, there are two common ways to locate unit test files: near the implementation code they are testing, and in a separate file hierarchy. The choice is a matter of what is the common practice in your organisation and personal taste.

Regarding the location of common test code, just organize your test code are you would organize implementation code.

In your particular case, if some test infrastructure is common to several independent components, it would be a good idea to create a new component (call it "testing", for example) that other components depends on for their tests, instead of adding dependences between existing components.

Answer 3

I usually organize such code in a file structure that looks (in a simple case) like this:

apps
    app1
        app1module1
        app2module2
        app1tests
    app2
        app2module1
        app2tests
components
    comp1
        comp1module1
        comp1module2
        comp1tests
common_test_stuff

There is no single right way to do this, but this seems to be a common practice that keeps production and test code separate and attempts to remove the out-of-sight, out-of-mind problem (mentioned by zac) at the same time.

Answer 4

Keep the test code close to the product code, and arrange your Makefile (or whatever you're using) so that the tests compile at the same time as the test, to make them visible, especially if not everyone in the team is writing tests.