Java 我们可以使用 JUNIT 进行自动化集成测试吗？

Can we use JUNIT for Automated Integration Testing?

提问by Eduardo Santa

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?

你如何自动化集成测试？我将 JUnit 用于其中一些测试。这是解决方案之一还是完全错误？你有什么建议？

采纳答案by Robin

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

JUnit 有效。没有将其限制为仅作为单元测试的限制。我们使用 JUnit、Maven 和 CruiseControl 来做 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.

可能有专门用于集成测试的工具，但我认为它们的用处取决于您要集成的系统组件的类型。JUnit 可以很好地用于非 UI 类型测试。

回答by eishay

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

确实！我们结合使用 JUnit、ANT 任务来运行它们，并使用Hudson进行持续集成测试。奇迹般有效。

回答by sblundy

When using Maven to build a project, I've had a little more luck with TestNGbecause it has @BeforeSuiteand @AfterSuiteoperations. 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.

在使用 Maven 构建项目时，我对TestNG 的运气好一些，因为它有@BeforeSuite和@AfterSuite操作。这很有用，因为如果任何集成测试失败，Maven 将不会执行“post-integration-test”。Ant 没有问题，所以我只是出于偏好使用 jUnit。

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

在任何一种情况下，像 TestNG 和 jUnit 一样分割测试也有助于集成测试。

回答by Arne Burmeister

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

是的，您可以使用 junit 进行集成测试，但这取决于您需要的集成测试类型。

Testing a servlet:

测试 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)

• 设置 servlet 上下文和配置
• 使用模拟 servlet 请求进行测试（Spring 对此提供支持，但您也可以使用 EasyMock 或您自己的模拟）

Testing a spring application:

测试 spring 应用程序：

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

• 使用 AbstractDependencyInjectionSpringContextTests 来设置上下文
• 测试有线豆
• 在使用数据库进行测试时，还有支持事务处理的 AbstractDependencyInjectionSpringContextTests 的子类。

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.

但纯 Junit 有其局限性。测试用户界面是一个典型案例。您可以将 selenium 用于 Web 应用程序，将 soapui 用于 Web 服务或其他合适的工具。

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

但是无论您使用什么，都应该可以将其集成到您的持续构建中（巡航控制、团队城市或其他）。

回答by Bob Cross

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

在我们的工作中，我们的集成测试解决方案包含三个主要部分：

1. CruiseControlis 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?". JUnitis 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?"

1. CruiseControl是我们持续集成方法的基础。
2. 我们的 CruiseControl 配置会在任何人签入Subversion后的 3 分钟内启动快速测试构建。这里发生的测试是“所有东西都能编译吗？” 和“单元测试是否仍然通过？”。 JUnit显然是回答第二个问题的主要推动者。
3. 每小时，它都会启动一个更大的构建，构建我们在各种部署平台上使用的在线帮助和安装程序。这一步验证了更大的问题：“我们是否仍然为每个目标平台提供可部署的产品？”

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 goodtests will always require thought and development time.

最终结果是这里的大多数人从不担心集成测试：它只是发生。另一方面，单元测试是每个人的首要任务。JUnit 使构建测试变得容易，尽管好的测试总是需要思考和开发时间。

回答by Johannes Brodwall

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.

我已经使用 JUnit 进行了大量集成测试。当然，集成测试可能意味着许多不同的事情。对于更多的系统级集成测试，我更喜欢让脚本从外部驱动我的测试过程。

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

对于使用 http 和数据库的应用程序，这是一种非常适合我的方法，我想验证整个堆栈：

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

1. 使用Hypersonic or H2的内存模式作为数据库更换（本最适合的ORM）
2. 在@BeforeSuite或等效中初始化数据库（再次：使用 ORM 最简单）
3. 使用 Jetty 启动进程内 Web 服务器。
4. @Before每次测试，清除数据库并使用必要的数据进行初始化
5. 用于JWebUnit向 Jetty 执行 HTTP 请求

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.

这为您提供了无需任何数据库或应用程序服务器设置即可运行的集成测试，并且可以从 http 向下运行堆栈。由于它不依赖于外部资源，因此该测试在构建服务器上运行良好。

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 JWebUniton Java.net.

对于那些想了解更多信息的人，我在 Java.net 上写了一篇关于使用 Jetty 和 JWebUnit进行嵌入式集成测试的文章。

回答by Jeffrey Fredrick

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.

我在 JUnit 中编写了集成测试，但我也看到人们使用 HtmlUnit（JUnit 扩展）、Selenium、Watir、Fit/Fitness，甚至像 WinRunner 和 Silk 这样的商业工具。

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

因此，请告诉我们更多有关您的领域和测试目标的信息，您可能会得到更好的答案。

回答by uthark

There is a very good extension for JUnit called Jitr.

JUnit 有一个非常好的扩展名为 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.

Jitr 是一个 JUnit 集成测试运行器，它允许您的 Web 应用程序集成测试轻松地在与您的测试相同的 JVM 中针对轻量级 Web 容器运行。

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

有关详细信息，请参阅他们的网站：http: //www.jitr.org/

回答by 8bitjunkie

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.

2012 年更新：虽然可以使用 JUnit（并受益于 CI 支持），但 JWebUnit 和 Selenium 似乎正在蚕食集成测试的思想份额。

回答by Dariusz Cieslak

I think automation and integration tests do not play well together. The very basic problem is environment setupbefore 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/

我对集成层测试自动化的看法：http: //blog.aplikacja.info/2012/03/whats-wrong-with-automated-integration-tests/