Integration Tests

Integration tests are nice. We all know that and love using them, don’t we? It’s just using all those databases, message brokers and other things as real dependencies, only wrapped by Testcontainers, might result in a really heavy CI/CD pipeline and developers’ attitude to never run them locally, because they’re so slooooooooooow. What if I could show you a number of techniques, mindset changes and tricks to get your integration tests shortened from quarters to seconds? Would that be interesting for you, to benefit from the confidence integrations tests give you, before you’re able to brew a fresh coffee? It’s really not about re-inventing the wheel, but using it the smart way.

Spoiler alert: this is a “from zero to hero” session. Assuming you’re familiar with programming (hopefully in Java), after this session you should be able to explain why Testcontainers are needed, simple and powerful 😉

The pyramids in Egypt were built in ancient times. We still admire them today, appreciating the craftsmanship and hard work of their builders. However, do we build houses from giant stone blocks today? Not likely, current times bring other needs and offer other technologies.

The pyramids in Egypt were built in ancient times. We still admire them today, appreciating the craftsmanship and hard work of their builders. However, do we build houses from giant stone blocks today? Not likely, current times bring other needs and offer other technologies.

Pyramids of testing were also built some time ago. We admire legacy projects with a rich set of tests, but do we create projects today the same way we did 10-15-20 years ago? If not, why do we still want to test them the same way?