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

I'd concur with f4's answer. Such kind of tests (level higher than UT) usually has no correlation with particular classes. Your tests should stick to project requirements and specifications.

In case you really need to develop a testing project tailored to your test requirements, I'd recommend the following approach: a separate project with packages per requirement or user story (depending on your approach to manage requirements). For example:

src/itest
  -package1 - corresponds to story#1
    -classA - test case1
    -classB - test case2
  -package2 - corresponds to story#1
    -classC - test case2
  -packageData - your common test data and utilities

However keep in mind - doing an integration or system-level tests is usually complicated task and its scope could easily be broader than testing software project can cover. You should be ready to consider a third-party test automation tools, because at the level of integration or system test it's often a more efficient approach than developing a tailored testing package.