|
|
||
John Ferguson Smart's BlogUnit tests are not integration testsPosted by johnsmart on June 12, 2008 at 05:09 PM | Comments (4)The classic difference between integration and unit testing is that unit tests run in isolation, or near-isolation. Using an in-memory database for DAO unit tests. Using mocked-out components for the other layers. Integration tests, on the other hand, test the whole stack. If you're using Spring, you inject the whole Spring context and try to flush out any configuration issues, or integration issues between the various layers. Integration tests tend to run slowly. Unit tests run fast. You don't want to slow down your quick coding turn-around time by running the integration tests every time - run them less frequently than the unit tests (there's usually no need to retest the Spring configuration files if you've only changed a couple of lines of code - you'll do this before you commit, anyway). Integration tests often have more of a BDD feel to them. They simulate, to some extent, expected user behavior. Unit tests can do this too, but integration tests do so at a higher level. This means they can be candidates for reuse later on for performance and scalability tests. This is even better if you add some parameters to your integration tests (e.g. by using JUnit 4.4 Theories) - this makes them much easier to reuse for more heavy-weight testing. I'll discuss this in more detail in the next installment. Personally, I materialize this distinction using naming conventions (e.g. ClientTest for a unit test, ClientIntegrationTest for an integration test). Then it's pretty easy to get each category of test to run at different times in the build cycle. In maven, it's as simple as 20 or so lines of XML :-), as shown here:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
<executions>
<execution>
<id>unit-tests</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<skip>false</skip>
<excludes>
<exclude>**/*IntegrationTest.java</exclude>
</excludes>
</configuration>
</execution>
<execution>
<id>integration-tests</id>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<skip>false</skip>
<includes>
<include>**/*IntegrationTest.java</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
A bit cumbersome, I admit. But, with this, you can use the standard Maven test command to run uniquely the unit tests: mvn test Then, to run just the integration tests, you run: mvn integration-test Naturally, you can do the same thing at a lower level in Ant with the JUnit Ant task. In TestNG, you can use test groups - this is one of the nice features of TestNG compared to JUnit 4.4. Next time: Performance Testing is not Scalability Testing Bookmark blog post: CommentsComments are listed in date ascending order (oldest first) | Post Comment
| ||
|
|