30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
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.
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 :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 :)