mbland / tomcat-servlet-testing-example / 6765432492

100%

push

github

Add embedded TestTomcat to TomcatContractTest

The original version of the test copies strcalc.war into a temporary
Docker container. It works really well, but since the Servlet runs in a
separate process, we can't collect code coverage for it.

I then tried to use Mockito to write a @SmallTest for
stringcalculator.Servlet, since HttpServletRequest and
HttpServletResponse are pretty broad interfaces. It worked, but
apparently Mockito's Java agent triggers deprecation warnings from Java
21 that don't bode well:

- https://github.com/mockito/mockito/issues/3037

Plus, I hate the idea of mocking HTTP requests and responses.

I got the idea to research embedding Tomcat in the same process, and it
turned out to be quite possible. I've included in the code comments
links to the documentation I found that helped me out.

The wins are:

- I can now successfully collect, display, and report code coverage for
  the stringcalculator.Servlet class.

- I retain a high degree of confidence in the integration between Tomcat
  and the Servlet, instead of mocking HttpServlet{Request,Response}.

- Launching and shutting down the embedded Tomcat server is so fast I
  don't have to call Threads.sleep(), speeding up the tests.

I'm still holding onto the LocalServer and related helper classes, as I
still want to use them to demonstrate @LargeTests.

This change also enables coverage for the test-medium Gradle task.
However, I'm thinking of introducing another JUnit tag and Gradle target
to identify medium sized contract tests from which I want to collect
coverage. I don't want code coverage from medium tests in general,
necessarily, but I do want it from medium contract tests for specific
integration points. (Usually I think of "internal API" wrappers when I
think of these contract tests. Even though the Servlet isn't quite such
a wrapper, it's still an adapter between the external framework (Tomcat)
and the internal logic (the forthcoming StringCalculator).

1 of 1 new or added line in 1 file covered. (100.0%)

5 of 5 relevant lines covered (100.0%)

2.8 hits per line