Testing in Elixir

Home / elixir / Testing in Elixir

Testing in Elixir

We are a testing shop in Rails. I wanted to take some of the same discipline that we had for Ruby over to the Elixir side.

If you want to skip to the punch line, this is it.

Test all of your code with pretty, isolated, fast tests.

Let’s break it down.


We are a shop that writes tests. To me, it doesn’t matter if you write your tests or your code first. We test because we find that testing reduces mistakes, increases code quality by reducing coupling, and makes it easier to refactor code when we need to change.

ALL of your code,

If it’s worth writing, it’s worth testing. We measure our coverage, and we make sure we maintain 100% coverage. We find that life is easier when we can run tests with coverage at any point in time, and answer basic questions. All of our tests must pass, and our coverage must be 100%. Eric has dropped in a few pull requests for coveralls to make it easy to get to a reasonable coverage level, things like skip file configuration and the like. For the most part, though, we’ll code it in such a way that we can test.

with PRETTY,

Tests are first class code. We try to maintain good coding hygiene in tests just as we do in the rest of the code base. We’ve released a framework called shouldi that lets us factor out repeated setup behavior through nested contexts, and we try to keep the syntax beautiful and as free of repetition as we can make it.

Here’s an example of some code that tests a get to /:

Simple, clean, and to the point. Additional tests can share the setup, which calls the route to /.


Each new function has at least two clients: the production code that calls it, and the test that calls it. Functional code is great for separating those responsibilities. We simulate rather than call external services, and we generate fake data to put through our tests. We have a couple of quick-and-dirty files that help us build test structs, saved and unsaved, collection or singular.

FAST tests.

Keeping code fast means keeping tests parallel. That means no mocking. With functional code, it’s easy enough to write decoupled code without requiring mocks. To us, a test is a first class client with its own requirements. Sometimes, shared resources require some thought to keep each resource unique. For example, for us, database resources are scoped to a company, so creating a new company with a name based on the process id and test lets us run most database tests in parallel.

In the weeks to come, we’re going to tell you a little more about how we do all of the above.

Bruce Tate
Bruce Tate
Bruce Tate is the CTO of icanmakeitbetter.com, and author of more than 10 books, including the best-selling Seven Languages in Seven Weeks.
Recent Posts

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you as soon as possible!

WordPress Lightbox Plugin