Testing is a fairly crucial part of building a scalable, reliable application. It’s impossible to confidently deploy simple (or complicated!) changes without being sure that nothing will break. And, working with TeachBack, the last thing I want to do is end up spending my time fixing bugs introduced by fast development.
However, there’s an interesting question to be asked. To what level do you test - and how brittle should those tests be? For instance, when you want to test a redux store, should you raise an action and make sure that the correct dispatches have been sent through the store? If you’re working on a frontend applications, should your tests cover the page layout and UX elements to a fine grain?
Yes, this will help you make sure things don’t break when you ship. But brittle tests discourage refactoring, code cleanup and small changes. If I want to change the behavior of my application (or re-theme my website), I sure as hell don’t want to spend 30% of my time rewriting tests “just so they past”.
What’s the solution here?
I’m a strong believe that simple code tests itself. Splitting out code into small, manageable chunks makes it easier to conceptually test your code. This definitively doesn’t stop you from shipping bugs, but it reduces the environment in which I write buggy code.