I test in production.
The last thing any programmer wants to do is write tests. And I get it, I’ve been there. Writing tests can be boring. And I’m not going to give you a long lecture about why you should write tests, I’m just going to show what we’ve done at Fuze over the course of the next 2-3 posts.
This particular post is about the fundamental unit of testing - Unit Testing.
To lay the foundation, our goal is to have greater than 99% test coverage for statements, branches, function and
lines.
The headline numbers at Fuze for Unit Testing right now are:
- Functions, Lines - 100%
- Statements - 99.4%
- Branches - 99.51%
This is for a non-trivial codebase of 120k LOC and over 1200 tests.
The big question is not why, it’s how and the answer at Fuze has been twofold:
Firstly, we have a complex system that has many moving parts, so everyone realizes the importance of testing and we’ve built a top-down ‘testing’ culture.
Secondly, we make testing fun.
- Our tests run under the target goal of
15s
, and at more than 1200 test cases, this is possible because we useswc
which usesRust
to speed up the tests. - We heavily rely on automations - GitHub Actions to run the tests. While we could have configured pre-commit hooks to run them we decided against it because it slows down development cycles.
In the new few posts I’ll talk about API testing, Integration tests, Stress Testing and Vulnerability
management.
Do let me know if you liked the above post in the comments below.