What is the best way to run integration tests using a web server?

Question

As the title says, I'm interested in the best approaches to testing the application using the Jetty web server, given that you do not want to start / stop the test server for each specific test.

As far as I know, these are the solutions:

• if you use a build tool like Maven or Gradle, you can do this in a *.pom or *.gradle .

  • This has the disadvantage that you need to create a test server in another way that you usually do in the application.

• Create a test suite and use the @BeforeClass and @AfterClass to start / stop the server before / after the Suite test.

  • Disadvantage
  • is an "ugly" way of specifying tests to run. You must also indicate that the test that is added to the package should not run outside the set (avoid running the test again). I think Junit is not yet fully equipped for this.

• Create and start the server in a static way at the beginning of the tests and use the ShutDown mechanism to connect to the JVM and stop the server automatically when all tests are completed. This seems like the best solution, because this mechanism is already available in Jetty, but

  • The disadvantage is that you do not control server shutdown. This is done in fact in a completely different topic, even outside the build tool (I use Gradle for this)

Answer 1

We do # 2 for almost all of our tests at the pier. It’s actually very simple to create an embedded server and deploy the application, or servlet, or whatever you like about it. This gives you more than just the ability to run automated tests, as well as a way to debug your application simply in the IDE without any tool overhead. Thus, from the point of view of Jetty, we are big fans of creating your test suite and starting and stopping servers as necessary as part of this test. We have test cases when we deploy several servers and check the expiration of the session between them, others where we deploy the server and toss 10k client connections against it with our asynchronous berth. Just starting a full berth assembly starts and stops hundreds of berth server instances.

Not every application can be connected in this way, some of them have external database requirements and the like, but even there you can often write unit tests against a database in memory, for example, derby, which is a great approach to sharing your tests. If you absolutely need an environment to run your tests, many people are lucky with a combination of maven, plugty-maven-plugin and things like selenium, but I usually see them as more functional testing or acceptance test scripts, the actual mod A thorough test should be done in the context of the junit ... imo test at least.

Answer 2

We use the Jenkins build pipeline using the Build Pipeline Plugin . The first task starts the build and creates an artifact that includes all the compiled code, including the WAR file and all the compiled test code.

Then begins the initial task, which deploys the WAR file on the real Tomcat server.

Subsequently, we have a job that runs integration tests (getting tests from a test artifact from an upstream build) against a real Tomcat server.

There is more than that, but it is a general idea.