Test-Suite Friction and Design

Every line of code in an application, whether for testing purposes or not, is code that needs maintenance.

Tests are a form of documentation. A potential reader must understand what is going on with the production code and the tests. Having a lot of quirks and abstractions as part of the test setup hides that benefit.

Test code is untested code. It is best to keep it to the most negligible, not coverage but setup. Make it as dull as possible.

Good tests tell a story of what the code under test should look like. The required setup might say missing abstractions in the system’s design. A test suite creating any friction might be a sign of design problems.

The test-suite doesn’t need optimization, parallelism, or fancy tooling. The design of the application is what needs care. Focus on production code when the tests are creating any pain or conflict.

When we experience test pain, the first thing I look for is there’s something wrong with the production code that led me there[¹]

—

[¹]: Justin Searls(2015): RubyConf 2015 — How to Stop Hating your Test Suite by Justin Searls([https://www.youtube.com/watch?v=VD51AkG8EZw](https://www.youtube.com/watch?v=VD51AkG8EZw))