Has it ever felt like something is pointless by design?
There’s a Sailor Moon meme wherein Tuxedo Mask appears, does nothing, then leaves asserting ‘my job here is done’ – meanwhile Sailor Moon rebuffs ‘but you didnt do anything!’
It’s easy to see the unappealing nature of unit tests. A developer writes code, a developer writes a tiny test for that specific code – that obviously passes. There’s a reason QA exists outside Developers – having people test their own work comes with a number of psychological barriers that tends to result in oversights in testing.
Meanwhile refactoring the code usually means also refactoring the tests, so they are not catching refactoring problems. Sure, the tests may document expected functionality and may inform you to some edge cases to account for in your redesign – but ultimately it will most likely be your integration tests that actually catch accidental bugs due to unexpected changes in functionality.
And yet the unit tests run. Automatically. Sometimes every time you save any file in the project. ‘My work here is done’ they say, every time they pass. But what did they do exactly?
Answer: they ran.
They exist.
See, automation of all kinds requires a degree of due process. A certain rigidity. E2E requires reliable selectors, integration tests require data contracts, and unit tests – unit tests require code standards. Unit test frameworks require your codebase be structured in a testable way – the code itself must adhere to certain expected standards.
By implementing and maintain a unit test framework, you enforced certain best practices within your code base. Simply having a linter can eliminate critical coding errors from being written – thus saving you errors at test time. In the era of Javascript free-for-all coding, these often overlooked aspects of programming are more important then ever, and unit tests mere existence holds you accountable.
Unit tests keep your codebase testable.