Can we use JUNIT for Automated Integration Testing

问题:

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?

回答1:

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.

回答2:

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();
}

// From JWebUnit
private WebTestCase tester = new WebTestCase();

@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 article about Embedded Integration Tests with Jetty and JWebUnit on Java.net.

回答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.

回答4:

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.

回答5:

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).

回答6:

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

回答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.

回答8:

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/

回答9:

Update for 2012: Whilst JUnit can be used (and benefits from CI support) JWebUnit and Selenium appear to be eating up the mindshare for Integration Testing.

回答10:

I think automation and integration tests do not play well together. The very basic problem is environment setup before every test. The more integration-type test bigger setup is needed.

My thoughts on test automation on integration layer: http://blog.aplikacja.info/2012/03/whats-wrong-with-automated-integration-tests/