Separation of integration and unit test source

[eliot]

Hi all,

I've got my Java source files split up in directories as follows:

src
    - java (contains application code)
    - test (contains unit and integration tests and package structure mirrors the application code tree)

My TestCases are mostly unit tests, however some TestCases are integration tests (these usually access the database), or a combination of unit and integration tests.

I feel a need for a strategy to separate my unit and integration tests from each other, so for example, I can easily run all my unit tests without running the (lengthy) integration tests.

Have any forum members got any suggestions for how to do this? What's worked for you in the past?

In case it makes a difference, I'm using Maven as my build tool.

Regards,
Eliot

[robh]

Eliot,

I can't speak for Maven integration but I tend to have a test folder with unit and integration sub-folders. Plus you may opt to have different output directories for both types of test so that you can run them independently. I did mess about with naming conventions for a while but I found this approach to be much better.

I use Ant for building but I guess you can get this to work with Maven.

Regards,

Rob

[Ben Alex]

Don't forget stress testing either. I've done a lot with Grinder 3 lately, and thoroughly recommend it: http://grinder.sourceforge.net. For stress testing we also found it helpful writing a Populator class to generate lots of rows (via Hibernate), and then dump them to a file using standard database tools. The dump can then be imported before each stress test iteration, providing both a baseline for measuring further changes and a useful reflection of what we expect is the scale of the production system. It also helps the customer delivery, as you can show them repeatable (there is a dump they can install) application response times.

These sort of consistent stress test "database start points" are essential for scientifically measuring changes to things like indexes, lazy loading configuration, RDMBS parameters, web server parameters, cache settings etc. The benefit of a DB dump over say a DBUNIT script or a Java generation class is that an import process takes only a few minutes per hundred thousand rows. Also, often one will miss appreciable performance gains (or losses) if not using a realistic sized database baseline, giving credibility to a dump + stress test process.

[dwsmith75]

Maybe you should look at TestNG, its support "test-groups" . You could define int test and unit test and run either or both

http://www.beust.com/testng/

[rstearns01]

I did mess about with naming conventions for a while but I found this approach to be much better.

I'm 'still' using naming conventions. Having just begun exploring Maven, though, the separate folder approach might work better as you could create separate build targets for each level of testing rather than separate test execution targets.