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 test with coverage at any point in time, and answer basic questions. All of our tests must past, 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.
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.
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 it’s 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.