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)
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 :)