Add integration tests

[felixbarny]

Consider using https://www.testcontainers.org.

[bsideup]

Hi @felixbarny!

Testcontainers' member is here :) I'm happy to answer questions if you have any to make it happen :)

The main reason why I joined Testcontainers projects because we (ZeroTurnaround back then) wanted to test our APMs and Java Agents and it was painful without Docker given the complexity of setup, it seems that your motivation is quite the same :)

You can check one of my sample projects:
https://github.com/bsideup/javaagent-boilerplate/tree/master/src

P.S. If you happen to be in Berlin, you can let me know (short notice is ok) if you want to have coffee / beers and talk about TC and APMs in general :)

[felixbarny]

seems that you motivation is quite the same :)

yes, indeed :D

Thanks for offering your help, I'll get back to it! I think I stumbled upon your repo some time ago, didn't realize the testcontainers stuff in it though :D

I live in Munich, but when I'm in Berlin, I'll let you know 🍻

Are you usually adding the integration tests into the same repo or do you create a separate one for it?

[bsideup]

@felixbarny that example is heavily inspired by what we did at ZeroTurnaround and contains some abstractions to make it even simpler to write tests, I didn't realize that it actually hides the Testcontainers usage :D

I would recommend to keep tests next to the project, since they are actually quite fast and help to do test-driven development by testing your change even before committing it. This is also how we did it in Zipkin when I helped them

[felixbarny]

This issue is just about having a simple proof of concept integration test which deploys a war to a tomcat server and reports transactions to a mock apm server (in contrast to #55). The transactions can then be verified using plain AssertJ assertions. Also, the application deployed on tomcat should be easily debuggable.

Going forward, these type of integration tests will verify the agent's correct behavior across different application servers, frameworks, JVM vendors and different versions of these. This can become quite a complex build matrix, which could be managed either by Jenkins or just using parameterized JUnit tests, which use version parameters, for example to test different tomcat versions.

It also probably makes sense to not execute the integration tests by default but only when a special maven profile is set. That way, it's possible to only execute the unit tests without the potentially slower integration tests (testcontainers is quite fast though).