Testcontainers Integration Library Gets Commercial Backing with AtomicJar
The founders of the open source integration testing library Testcontainers have launched a startup called AtomicJar to make it easier for developers to understand how well applications integrate with external resources before those apps go into production.
Richard North created Testcontainers in 2015 while chief engineer at Deloitte Digital. Co-founder Sergei Egorov, a former staff engineer at Pivotal and contributor to a variety of open source projects, joined him in the endeavor five years ago.
They announced the new company and a $4 million seed round led by Boldstart Ventures at the JLove conference, this week.
“It’s a massive opportunity because applications keep getting more distributed with more dependencies, and companies want to find these integration problems earlier in the software development lifecycle,” said Ed Sim, founder and managing partner at Boldstart Ventures.
North created Testcontainers to address a common problem he encountered in consulting work: the pain of integration testing. It’s critically important, yet has been treated as too hard and too hard to get right, he said.
When “you are developing a piece of software, you have a piece of code that needs to interact with an external dependency, like a database, or message queue or some other kind of resource, you want to ensure that your code that you’ve just written works correctly when you connect it to this thing,” he explained.
“And traditionally, there were two ways of doing this: One was you actually connected it to the real thing. But that requires you to actually configure and have running, like your real database, on your local dev machine and on your CI machine, and have exactly the same configuration for it on every developer’s machine, which was a painful, painful thing to get right. We lived through years of manually setting that up. And it wasn’t a particularly pleasant experience.
“And the other way that you could approach it is you just say, ‘OK, so this is the piece of code I’ve written to talk to my database Here’s what I know about how the database should behave. And I’m going to assume that as long as my code does what my expected test code says it should do, then it’s going to be OK.’ But then of course, you get to production, you find out some assumption you made about how your external dependency behaves is actually false. And then you have a failure that occurs for the first time in production or new staging environment, or whatever, [and] it’s a long time after the code was originally written.”
As Docker was gaining popularity, it presented a way to easily and quickly create replicas of the things you would be connecting to in production, have them run for the duration of the test suite, then be torn down again afterwards, he said.
Testcontainers is an open source library that lets developers use their code to “test with containers” for dependencies such as data stores and databases Redis, PostgreSQL), to anything else that can run in a Docker container (Kafka, RabbitMQ, Selenium, etc.).
“And so what we do for Testcontainers, we created this framework, which would integrate with your testing libraries, and we’ll provide these dependencies for you so you would declare what they were like — the image name, the ports they needed to expose, things like your initial schema that needed to be loaded into the dependency, all sorts of things like that — you would write it in code so that every developer would get it. All they need to do is have the library and have the same code for their tests, and they will get an exact replica of a dependency the same as every everybody else on the team,” he said.
Testcontainers is downloaded more than 1 million times per month by companies such as Spotify, Google, Instana, Oracle, Zalando and others.
“Because of the flexibility of Docker images, Testcontainers modules can now spin up containers with databases, web browsers, or mock AWS endpoints. This is what makes Testcontainers powerful for functional testing — it provides a flexible way of standing up dependencies before your code starts,” states a Capitol One blog.
As a company, AtomicJar doesn’t plan to take anything away from the open source project and will continue its development, according to Egorov.
“We didn’t want to start something like Testcontainers Pro or Testcontainers for enterprises. But instead, we realize that we have a huge opportunity for complimentary product … to make it much easier to run Testcontainers-based tests,” he said. It plans to introduce by the end of the year a SaaS product, but for now is concentrating on helping customers have a better experience with the testing solution. It wants to make testing faster, more secure and work with customers who want to test, but perhaps don’t even deploy to production.
Competing technologies are based more on categories, according to Egorov, such as Cypress.io for browser testing. AtomJar is in talks about partnering up with it, he said, while products such as Garden.io and Tilt and up9 and others are focused on replicating production environments and on Kubernetes.
“In our case, we provide a generic tool that doesn’t require anyone to start deploying to Kubernetes just so that they can test something,” he said. “Sometimes you don’t even have production. Sometimes maybe you just started developing your service, and there is no production, but you want to run your tests already,” Egorov said.
“Testcontainers gives developers exactly that. And it helps them take all these details away, this complexity of running test dependencies, while not having to think, ‘OK, I need to deploy it to production for just so I can test it,’ because that’s the wrong way of thinking how testing should be done.”
AtomicJar is opening a private beta for a limited number of enterprises to try the enhancements and extensions the company has added to Testcontainers. Join the waiting list here.