Why Integration Testing is Taking Off

Java developers are well familiar with unit testing — so much so that for many dev teams, unit testing is baked into the build, and failing a unit test “breaks the build.”

But companies like Google are steadily championing integration testing as a new category. In a post last week, George Pirocanac in a Google Testing Blog post titled “How Much Testing is Enough” specifically encouraged “don’t skimp on integration testing” and went on to say “As the codebase grows and reaches a point where numbers of functional units are available to test as a group, it’s time to have a solid base of integration tests.”

To learn more about integration testing, JAXenter spoke with Richard North, creator of integration testing’s most popular open source project, Testcontainers. Today in a keynote at the jLove conference, North and co-founder Sergei Egorov announced that the Testcontainers project received $4M in seed funding, and that the project is on a mission to make integration testing so easy that it’s part of every build.

SEE ALSO: Developing AGI: Where We Are and What the Future Holds

JAXenter: Tell us a little bit about why you created Testcontainers in the first place?

Richard North: When applications integrate with external resources like databases and complicated dependencies, developers need to know how the application will behave once it has been deployed to the real environment. Integration testing allows developers to verify each of these integration points behaves correctly, before deployment.

I created Testcontainers while working as a software engineering consultant. At that time, integration testing was such a mess. It was hopelessly complicated to set up consistent local set-ups, configure databases, and some technologies were in fact so hard to set up integration tests for, that teams would exclude adopting them because they were too hard to test.

Then Docker came along, and proved to be a perfect abstraction layer for integration testing. Docker allowed the description of what’s inside containers very simple and extensible to test teams, and made it possible to push integration test abstractions to developers. I basically figured out a reasonable API to sit atop Docker, optimized for integration testing, and that’s how Testcontainers were born.

Testcontainers made integration testing much easier by providing lightweight, throwaway instances of the kinds of dependencies people need to involve in their integration tests: common databases, Selenium web browser, or anything else that can run in a Docker container. Expressing these dependencies in plain Java code made it easy for developers to re-use and evolve their integration testing setup over time.

JAXenter: Who is using Testcontainers today in the Java ecosystem?

Richard North: Testcontainers is downloaded more than one million times per month by thousands of companies–including Spotify, Google, Skyscanner, Instana, Wise (formerly TransferWise), Zalando, and many more. Testcontainers is also heavily used by by the ecosystem of framework providers (VMware, Red Hat, Oracle, Microsoft, Lightbend) and database providers (Elastic, Couchbase, Confluent, StreamNative, Datastax, Splunk, Trino, Oracle Database, IBM DB2, Neo4J, Exasol, HiveMQ) as a staple for testing highly distributed services against complicated production dependencies.

JAXenter: With the news that you have received seed funding, how will this affect the community of Testcontainers users?

Richard North: It is only going to be a positive impact on our existing Testcontainers user community. We are keeping the same license. We are not creating a different enterprise version or otherwise choking the open source code in any way.

In fact, quite the opposite – we were struggling recently to scale the Testcontainers to support the backlog of feature requests, and to accommodate additional frameworks and technologies that wanted to ship with built-in support of Testcontainers. Testcontainers had been a side project to that point, but here we faced all these amazing opportunities to extend the framework, but lacked the engineering resources. We are excited to be able to put more resources into the Tescontainers project, and to develop products that are complementary to Testcontainers and that should make the lives of our users even easier.

SEE ALSO: Kubernetes-Managed Object Storage for the Win

JAXenter: Integration testing seems to be having its moment, where it is breaking out from a rather obscure sub-discipline of testing, to much more mainstream, with even companies like Uber blogging about how Testcontainers helped them overcome “flaky tests.” Why the rise in integration testing today?

Richard North: I think with the mass adoption of microservices, a lot of dev teams that have been rewriting their monoliths into microservices are asking, “why don’t I set up testing from day one, so I don’t end up with another not-testable version of this application in the the future?” And Testcontainers and integration testing gives them that – rather than spending time fighting with their test environments, they can focus more on the business logic and what they are actually being paid for.

Another consideration I think is that the ecosystem of supporting technologies has kept maturing, and people have been more ready to go beyond a narrow 3-tier architecture where they’d have just a single database as a dependency. Developers have this huge variety of external components that their applications need to touch, and so there is a legitimate testing pain there that only integration tests can handle. Every layer of technology choice – not just the database, but message queues, message brokers and more – benefit from a generic test solution that can test integration against each of these components in a consistent way.

The post Why Integration Testing is Taking Off appeared first on JAXenter.