Today I joined the AtomicJar team working on making integration tests simpler, more efficient, and a much more prominent tool for all developers.
It’s a very exciting opportunity and I’m thrilled at the impact we can have on the enormous developer community across multiple language ecosystems and thousands of projects. Here are a few reasons AtomicJar is an amazing company to put your efforts in.
At the heart of the AtomicJar technology is the Testcontainers project and the ideas it popularised initially in the Java ecosystem.
Testcontainers is a collection of libraries that integrate with your tests and provides lightweight, ephemeral instances of common third-party services you need: databases, message queues, text search engines, Kafkas, and Redises, and Mockservers, and if needed even the browsers for your UI tests.
All these services can be easily programmatically managed as containers that are aware of your tests’ lifecycle and turn running your integration tests into bliss.
You can find the details and typical usage patterns on the website: testcontainers.org, but if you haven’t seen it at all here’s a one-liner to awe in delight.
Setting up a Kafka instance programmatically:
KafkaContainer kafka =
And then you can access it programmatically too with something like
kafka.getBootstrapServers(). There’s of course API for every particular type of service that makes sense for them: databases, caches, search engines.
With Testcontainers it’s so easy to create proper integration tests with it and the user experience is so smooth that it’s really easy to fall in love with the technology.
Here’s what James Ward said about Testcontainers about a year ago, and it’s as valid now as ever.
And trust me, James knows a thing or two about technology, productivity, and developer experience.
Technology and the product are only a part of the equation. What sets AtomicJar apart is the emphasis on the success of the community.
There are currently thousands of users of the testcontainers libraries. They are also not limited to the Java ecosystem, there’re for example:
You get the point, having better integration tests is not limited to a particular language. All our projects could have better and faster integration tests.
Here’s for example a blogpost by Ricardo Ferreira about using testcontainers to manage Elasticsearch from golang tests.
I’m not an expert in go, but it looks neat, doesn’t it?
As a developer advocate, I’m thrilled to work with the diverse communities of various ecosystems!
If you don’t have enough of those, you can join the Slack workspace for the project and hang out with cool people there.
Very often companies market themselves as being for developers by developers. In the case of AtomicJar, I feel it’s really the case. Open source is at the heart of the company, the team understands developers, we even participate in various initiatives like opencollective to support OSS projects.
It is also an excellent opportunity to see a company grow and establish itself from the early stages which is an experience I welcome very-very much.
And since you’ve read so far already, you clearly have a few minutes on your hands. Why not write a new integration test for the project you’re working on? Who knows maybe you can even try a cool library that makes integration tests simpler. 😉