Testing is a critical part of software development process. And there is a ton of literature on when and how to test.
I'm not a big fun of sticking to any particular approach just because it's currently popular.
Over the course of time I found a simple way to identify potential candidate for tests in my code:
As I write a piece of the code, very often, I start to feel uncertain whether it will work or not. This feeling is accompanied by the urge to execute the code and validate its behaviour at runtime.
Well, this for me is a strong indicator that I should write tests.
Having said that, please mind that I'm talking about potential candidate. Sometimes (rarely), on second thought, I come to conclusion that no tests are needed.
Top comments (2)
IME this is a good way to decide if you want tests for yourself, to maintain your confidence that your translation of a specification/design is working as intended.
Sometimes this is sufficient overall, for small systems or personal work. As soon as other people are involved, they typically make assumptions about the system's behaviour which are also worth codifying into tests, thus ensuring that everyone's understanding of the specification/design is correct - particularly when considering unhappy paths / failure behaviour! The process of creating such tests is also a great way to ensure the specification/design is adequate... (hint: it usually is not!)
Finally there may be paying customers, or other teams consuming your system, and they too have expectations of system behaviour that should be maintained, in the form of consumer contract tests (preferably provided by the consumer!), this way the local team can deliver changes confidently, knowing that that won't be breaking the experience for their consumers.
Thank you for the comment. I completely agree.
There are plenty of different useful types of tests (uat, integration, security, performance etc.). Some of them are required by the customer. Also when you work as a team you have to have a common notion on what and how to test.
My rule of thumb is something i use at my work as a developer whenever i have opportunity to do so. Those are low-level tests that act as a first line of defence :)