On a project I've been working on, we've been steadily increasing the code coverage through tests. Some of these tests were done as integration tests, and some as unit tests. The integration tests can sometimes take a long time, thus discouraging users from running the entire test suite prior to checking in (and understandably so). What are some recommended strategies for separating unit tests from integration tests in such a way that we can easily run both from Hudson, while allowing code coverage statistics for both the unit tests alone and both sets of tests combined? (I'm assuming there's no value in getting the code coverage statistics rom the integration tests alone, but if you think that's a bad assumption, please let me know that as well.)
Specifically, this is a Java application using Maven as the build manager and Subversion as the version control system, with most developers using a NetBeans IDE, and also using Spring heavily along with some new JMockit and AspectJ code.
The types of things I'm wanting to know are:
- Currently, NetBeans has a tool for automatically creating Unit Tests for you. It puts them in a src\test directory hierarchy that mirrors the src\main directory hierarchy for your main project. Should I create a src\integrationTest directory or something to specifically house integration tests to make for easy separation, or is it typical to use a naming convention to distinguish between the two types of tests, or perhaps an Annotation?
- Along the same lines as #1, are there any Maven patterns for separating integration tests from unit tests?
- Is there a standard check-in hook for Subversion to force developers to run the unit tests, but not the integration tests, prior to check-in? (This last one is less important than #1 or #2, but would still be nice.)
Alternatively, if you've got experience doing this with different tools, I'd like to hear what your practices are there as well. It could be that a good practice with another set of tools maps to my set of tools fairly simply.