Managing code: Unit tests with source or separate?

Question

The standard practice in the Objective C world has been to follow that laid down in the Java world when it comes to code management. i.e. Your application source code goes in one directory, and your unit test code goes in another.

I've always found this a bit of a pain. Especially as I tend to organise XCode the same way. The issues that annoy me are:

• Having to keep all the various groups in sync in terms of naming, etc.
• Not easily being able to see which classes have matching test classes.
• Having to scroll up and down through hierarchies all the time as I'm bouncing between tests and source.

So I've been thinking - What if I put the test code beside the source code? In the same directory. And in XCode I can then have the test code sitting with the source and easily locate and see the matching classes.

Has anyone tried this? Is it workable? Or is there another solution?

Answer 1

As Uncle Bob always says, your tests should not be coupled to the structure of your application (great blog discussing this topic).

Doing what you're suggesting sounds like you may run into issues with deployment, or other aspects of development... But the biggest issue I see is you'll be tempted to (if not forced to) couple your test-suite tot your application structure.

I wouldn't recommend allowing yourself to deal with the world of future headaches (from something simple such as a small package refactor) that come with this decision.

Answer 2

I tried this and won't recommend it... if you have only a few of classes per package could seem nice but, let's imagine a package with 20 production classes.. it will have 20 tests files placed there also? For me will be too much...

Furthermore, maybe with that structure that is not following the standard convention you should need to configure manually some of the features of your build tool/CI pipeline with an specific setup and this, in my opinion, doesn't foster interoperability

Regarding the pains you mention I think with a modern IDE they can be solved:

• Having to keep all the various groups in sync in terms of naming, etc

This can be solved by using the functionalities included to generate the tests automatically. If then you are changing the name of the class, you can change it by the IDE that will change the name itself and all its references, including the test related name.

• Not easily being able to see which classes have matching test classes.

Again modern IDE has a functionality to easily check which test sources are pointing to your production class, even if there are many tests spread through different files

• Having to scroll up and down through hierarchies all the time as I'm bouncing between tests and source.

Same here, if you right click in any class you will have an option to go to the tests and a button to go back is also provided.

All of these nice features that the IDE provides will be subject to manual configuration if you take the approach mentioned in your question.