Driving unit test coverage is essential but very dull. We need to make it as fun as possible. And for the “shippable” OSS products, it’s vital. It differs from the SaaS world, where you roll out an emergency release for all users. Once a user downloads something and runs it in their environment — it’s done. You cannot effortlessly swap the binary artifact. And if it’s broken — it’s your fault. The best way to prevent this is decent unit-testing coverage. This time we’ll cover something boring and automatable — API calls to a predefined service. Writing unit tests can be boring for a few reasons:
- Repetitive nature. Tasks are repetitive. More often than you hope. Setting up test data and checking the outputs. Monotonous and tedious.
- Lack of creativity. That’s where you need attention to detail. It’s less engaging for developers who enjoy more creative aspects of programming. Do YOU write tests creatively?
- Time-consuming. It can take significant time, especially for large or complex codebases. It frustrates developers eager to move on to new projects or features. They practice TDD, don’t they?
- Lack of immediate feedback. All these emojis in test runners can’t make test suites engaging. Unit tests may only show the results once the whole suite of tests is run. Not fun for some developers. Not fun for slow tests.
But it’s important to remember that writing unit tests is essential. It is the software development process. It can help ensure the code works as…