There is no shortage of material on testing and why all good programmers need to do it. If you really want to stand out, you follow the Test Driven and test first method.

Maybe you should, but not because you want to catch bugs or errors. Writing tests first is a *design technique * enabling you to write loosely coupled code with low cohesion. Not magically, of course, you can still create code which is anything but that throwing mocks and things at your design problem.

This is why I often write tests and I sometimes write them first. Notice the word often, as being dogmatic is just tiring and it’s usually not worth it. Programming isn’t always the same repetitive task of “just implementing” something. Sometimes you know exactly what to make and you’ve done it before so you can just write it without thinking much.

Exploration

Other times you might need to poke around to figure out what the problems is and how to solve it. I find a test driven approach for this an ideal tool, especially when writing the tests for the inside *out. Looking at what you want out of a module, class, service or component is a great starting point when you’re not really sure about how to get there. Having the goals articulated, you can start poking around. Most likely you get it wrong, you adjust the test and proceed.

Collaboration

I have become huge fan of remote group programming and I find they work best when you have tests to help drive sessions. It put an emphasis on the outcomes and you get to share knowledge about this as a group. Exploring a problem domain together like this is very efficient and fun. It’s a much better arena to create a consensus on how to do thing than the pull requests we for some reason all love.

It’s not about catching errors really

I have seen projects with 100% test coverage on every parts of their stack. This would often include things like browser tests with things like Playwrite. The amount of code to maintain and update gets quite monumental. You get issues with builds taking long and tests being brittle. We know that story and we remember the testing pyramid: You want to emphasize the tests lower down in the stack.

When you have a full battery of browser tests for your app, to me, it makes no sense. Regardless of the type of app, you don’t need it and you sure don’t need picture comparison tests. No exceptions! What you do need is to have a concept of what is the critical part of your app. This could be “what makes money”, “what’s the central task to perform”. Here is where you put some kind of test to ensure it always work when deploying. It can be a browser test or it came be some other type of test which ensures the same thing: users can do their thing.

Pixel perfection is only required for catering to the ego of the people involved in making the service. Users don’t care (I’ve been doing frontend for 20+ years and users don’t care… as long as they can get their thing done, our precious design implementation don’t matter).

Concluding on this rant passage:

  • you hardly need browser tests
  • tests isn’t about catching bugs but making sure important things work
  • some things don’t need tests, let it go

There is a huge caveat here: What I just said goes for web based application development. There are other contexts where you perhaps need a different strategy. Library application which has a huge number of downstream users? Native apps which has the release cadence from another century needs a different mindset, as goes for hardware development.

If you make a web app…. you need to make sure you’re not just putting up tests to cater to your own feeling of being a Craftsperson.

There are context where you might skip tests all together. If you’re a you company that needs to ship fast to get feedback, you can choose to optimize for fixing things fast rather than building a safety net. You install monitoring and invest in a rapid continuous delivery setup. Keeping the finger on the pulse of the app at all times and responding quickly can be what you need. Writing tests take time, effort and maintenance. Sometimes you just don’t have time. You can’t go down this route forever of course. Adding more people will make this approach hard, the same would adding more complexity to what the app does. It’s a temporary state to get feedback quick, but it’ll have to evolve into something else at some point.

In closing - ❤️ tests

I went on a bit of a tangent there, but the bottom line is that tests, test first coding done in a group session is amazing. Especially remote it’s a great tool and one that you should embrace, it requires little effort and have enormous gains.

Testing strategies and approaches vary depending on the context you are in. Don’t just blindly copy what you see others do or what you did last project. Think and decide with your product people what approach to take.

Tests are about design, communication and collaboration. With the side effect of sometimes catching bugs. I have found this perspective helps me a lot ❤️