How to organize integration tests?

Question

When writing unit tests, I usually have one test class per production class, so my hierarchy will look something like that:

src/main
  -package1
    -classA
    -classB
  -package2
    -classC
src/test
  -package1
    -classATests
    -classBTests
  -package2
    -classCTests

However when doing integration tests the organization becomes less rigid. For example, I may have a test class that tests classA and classB in conjunction. Where would you put it? What about a test class that tests classA, classB and classC together?

Also, integration tests usually require external properties or configuration files. Where do you place them and do you use any naming convention for them?

Answer 1

Maybe create an integration tests directory under src/test? Sure, for integration tests the separation becomes less clear, but there's something that groups A,B and C together, no? I'd start with this and see how things go. It's tough to come up with a perfect solution right away and an "OK" solution is better than no solution.

Answer 2

Our integration tests tend to be organised the same way our specifications are. And they tend to be gathered by categories and/or feature.

Answer 3

It seems that your integration tests are higher level unit tests since you still bind them to one or more classes. Try to pick class that depends on all others (transitively) from the group and associate test with such class.

If you have true integration tests then association with concrete classes is of little value. Then tests are classified by application subject areas (domains) and by types of functionality. For example, domains are orders, shipments, invoices, entitlements, etc. and functionality types are transactional, web, messaging, batch, etc. Their permutations would give you nice first cut of how to organize integration tests.