Can we use JUNIT for Automated Integration Testing?

Question

How do you automate integration testing? I use JUnit for some of these tests. This is one of the solutions or is totally wrong? What do you suggest?

Answer 1

Definitely! We use a combination of JUnit, ANT tasks to run them, and Hudson for continues integration tests. Works like a charm.

Answer 2

JUnit works. There are no limitations that restrict it to being unit tests only. We use JUnit, Maven and CruiseControl to do CI.

There may be tools that are specific for integration testing, but I would think their usefulness is dependent on what type of system components you are integrating. JUnit will work fine for non UI type testing.

Answer 3

When using Maven to build a project, I've had a little more luck with TestNG because it has @BeforeSuite and @AfterSuite operations. Which are useful because Maven will not execute the 'post-integration-test` if any of the integration tests fail. Not a problem with Ant, so I just use jUnit out of preference with it.

In either case, segmenting out the tests as both TestNG and jUnit do is helpful with integration tests too.

Answer 4

Yes, you may use junit for integration tests, but it depends on the type of integration test you need.

Testing a servlet:

• setup the servlet context and config
• do the tests using mock servlet requests (Spring has support for this, but you may also use EasyMock or your own mocks)

Testing a spring application:

• use AbstractDependencyInjectionSpringContextTests to setup the context
• test the wired beans
• there are also subclasses of AbstractDependencyInjectionSpringContextTests supporting transaction handling when testing with a database.

But pure Junit has its limit. Testing user interfaces is a typical case. You may use selenium for web applications, soapui for webservices or other appropriate tools.

But whatever you use, it should be possible to integrate it in your continious build (cruise control, team city or whatever).

Answer 5

In our work here, our integration testing solution has three major parts:

1. CruiseControl is the foundation of our continuous integration methodology.
2. Our CruiseControl configuration kicks off a quick-test build within 3 minutes of anyone's checkin to Subversion. The tests that happen here are "does everything still compile?" and "do the unit tests all still pass?". JUnit is obviously the major facilitator in answering the second questions.
3. Every hour, it kicks off a larger build that constructs the online help and installers that we use on our various deployment platforms. This step verifies the bigger questions of "do we still have a deployable product for each of our target platforms?"

The end result is that most people here never worry about integration testing: it just happens. Unit testing, on the other hand, is everyone's priority. JUnit makes it easy to construct tests, though good tests will always require thought and development time.

Answer 6

I've used JUnit for doing a lot of integration testing. Integration testing can, of course, mean many different things. For more system level integration tests, I prefer to let scripts drive my testing process from outside.

Here's an approach that works well for me for applications that use http and databases and I want to verify the whole stack:

1. Use Hypersonic or H2 in in-memory mode as a replacement for the database (this works best for ORMs)
2. Initialize the database in @BeforeSuite or equivalent (again: easiest with ORMs)
3. Use Jetty to start an in-process web server.
4. @Before each test, clear the database and initialize with the necessary data
5. Use JWebUnit to execute HTTP requests towards Jetty

This gives you integration tests that can run without any setup of database or application server and that exercises the stack from http down. Since it has no dependencies on external resources, this test runs fine on the build server.

Here some of the code I use:

@BeforeClass
public static void startServer() throws Exception {
    System.setProperty("hibernate.hbm2ddl.auto", "create");
    System.setProperty("hibernate.dialect", "...");
    DriverManagerDataSource dataSource = new DriverManagerDataSource();
    dataSource.setJdbcUrl("jdbc:hsqldb:mem:mytest");
    new org.mortbay.jetty.plus.naming.Resource(
             "jdbc/primaryDs", dataSource);


    Server server = new Server(0);
    WebAppContext webAppContext = new WebAppContext("src/main/webapp", "/");
    server.addHandler(webAppContext);
    server.start();
    webServerPort = server.getConnectors()[0].getLocalPort();
}

@Before
public void createTestContext() {
    tester.getTestContext().setBaseUrl("http://localhost:" + webServerPort + "/");
    dao.deleteAll(dao.find(Product.class));
    dao.flushChanges();
}

@Test
public void createNewProduct() throws Exception {
    String productName = uniqueName("product");
    int price = 54222;

    tester.beginAt("/products/new.html");
    tester.setTextField("productName", productName);
    tester.setTextField("price", Integer.toString(price));
    tester.submit("Create");

    Collection<Product> products = dao.find(Product.class);
    assertEquals(1, products.size());
    Product product = products.iterator().next();
    assertEquals(productName, product.getProductName());
    assertEquals(price, product.getPrice());
}

For those who'd like to know more, I've written an articla article about Embedded Integration Tests with Jetty and JWebUnit on Java.net.

Answer 7

The suggestion depends on your application and your objective.

I've written integration tests in JUnit, but I've also seen people use HtmlUnit (JUnit extension), Selenium, Watir, Fit/Fitness, and even commercial tools like WinRunner and Silk.

So tell us a bit more about your domain and the objectives of your tests and you can probably get a better answer.

Answer 8

I also use JUnit for the purpose of integration testing, and I'm happy with it.

It is a good idea to separate the unit test suite from the integration test suite though, even if both are written in JUnit. You'd want your unit test suite to run instantaneously, so that you can run it before/after any change. For integration tests this may be harder to achieve, so you'll probably run them less often (once per hour, once per day).

Answer 9

There is a very good extension for JUnit called Jitr.

Jitr is a JUnit Integration Test Runner and it allows your web application integration tests to easily run against a lightweight web container in the same JVM as your tests.

See their site for details: http://www.jitr.org/

Answer 10

Regarding "There are no limitations that restrict it to being unit tests only," please see http://stackoverflow.com/questions/3144887/passing-junit-data-between-tests. Some interesting answers and suggestions there.