Where should I put my testing code in relation to the code it is testing?

Question

The two obvious places I can think of would be some sort of "testing" folder right next to the code I'm working on. So something like:

\project-code
    \my-feature
        \production-code
        \testing
            ***my tests***
    \co-workers-feature
        \production-code
        \testing

Or I could split out the testing code a completely separate hierarchy. So something like:

\project-code
    \my-feature
    \co-workers-feature
\testing-project-code
    \my-feature
        ***my tests***
    \co-workers-feature

I've seen a lot of frameworks use the second approach, but recently we've been putting our testing code within the production code mostly for convenience. Is one approach much better than the other or is there a best practice here?

Answer 1

I use the second option. That means I can ship the code without the tests if needed. Also from looking at the class or package I know where the unit tests for it are.

Here's a related question:

Do you put unit tests in same project or another project?

Answer 2

If its a website that you control then it does not hurt to have it all in the same folder. If its classic software that you release then it tends to be good practice to have it seperate as in case 2 so that you don't accidently cause any bloat when you release.

Answer 3

Put them where it is most convenient for you. You can set up your build system to remove them from the final product, if desired. Testing is a "best practice". Anything that makes testing easier without reducing its effectiveness is simply improving on a best practice.

Answer 4

To me, the first option makes more sense, especially from a SCM point of view: production code and testing code are nicely kept in sync (as they should) and, if you tag or branch your project, you tag or branch both production and test code in the same time (as they should).

Answer 5

I prefer to keep unit tests close. I have seen option 1 work well. For a small project, both approaches will work fine, but as the project gets bigger and bigger, it is harder to find and maintain the tests when they live in a very different part of the tree. If they are close, changing them will be natural when you change the product code. If they are far away, it takes more mental effort and will be ignored more. This means a greater chance that they will be out of sync.

Note that to do this you need a make system that allows for conditional compilation of the test directories. You don't want to have to build them every time. If you can't get that, a separate tree might be necessary.