Usually production failures do a good job of justifying testing. But then knee-jerk reactions cause the pendulum to swing too far (like mentioned in Dan's post that Ben mentioned).
I mainly implement unit tests on a subset of code. Tests are required for the main business logic. We use Dependency Rejection so that we don't have to mock IO intermixed with business logic, so it is not hard to do. I've also had to unit test finicky libraries that can fail subtly based on settings (i.e. reflection-based serialization). But I don't test much IO. We use code paths which are few and well-worn for IO. If there is a runtime IO error, it is because of outage. Then it becomes an admin (or cloud infrastructure / resilience) problem anyway.
That is in our later projects. Our legacy code is a big mess and we basically don't unit test it (only manual acceptance testing). And deploying it always feels like jumping out of a plane and attempting to put on the parachute as we fall. We have tried writing some unit tests for it, but to even do so requires significant and risky refactoring. Instead we've been carving off chunks and rewriting them to the newer style.
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.
Usually production failures do a good job of justifying testing. But then knee-jerk reactions cause the pendulum to swing too far (like mentioned in Dan's post that Ben mentioned).
I mainly implement unit tests on a subset of code. Tests are required for the main business logic. We use Dependency Rejection so that we don't have to mock IO intermixed with business logic, so it is not hard to do. I've also had to unit test finicky libraries that can fail subtly based on settings (i.e. reflection-based serialization). But I don't test much IO. We use code paths which are few and well-worn for IO. If there is a runtime IO error, it is because of outage. Then it becomes an admin (or cloud infrastructure / resilience) problem anyway.
That is in our later projects. Our legacy code is a big mess and we basically don't unit test it (only manual acceptance testing). And deploying it always feels like jumping out of a plane and attempting to put on the parachute as we fall. We have tried writing some unit tests for it, but to even do so requires significant and risky refactoring. Instead we've been carving off chunks and rewriting them to the newer style.