At EverTrue we’re big believers in testing our code, but it wasn’t always that way.

EverTrue is still a very young company and one of the the engineering exercises that often gets forgotten is testing. Name your excuse as to why but the storyline is all too familiar. You have a small amount of resources and time and some things have to get cut.

Going forward, we’re taking a different attitude towards testing. When we create a new API, we’re diligent about test coverage. Our goal is to achieve >= 90% coverage.

We’re not adhering to TDD across the board, the approach is left up to the individual developer. If a developer wants to write tests after he or she is code complete we’re fine with that. Ultimately, as a team, we want test coverage to not drop before shipping to production, and ideally before going into master.

Developers are measured against the test coverage of individual projects so as to create another incentive besides the many that already exist with testing.

One of the best things that our team has come to like about writing tests is that it serves the purpose of providing documentation. There’s nothing worse than a source file rife with outdated code comments and no test to explicitly define its behavior.

While our engineering culture is a work in progress, this aspect of it seems to well embraced by the team and we’re looking forward to iterating on it to make even better. Come help us define our culture: careers@evertrue.com.