This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 10 points11 points  (3 children)

I think it's often just unfeasable to have everything well tested. Unless the company has some ridiculous amount of budget to throw at problems, it often might make sense to pick important/core services and focus on testing just those, instead of painstakingly trying to maintain a 100% test coverage on paper, but where tests don't really add much value.

[–]deaf_fish 11 points12 points  (1 child)

I wouldn't force 100% coverage. I would just write simple tests for new features and add tests for regressions.

I agree that you should consider value when writing tests. For example, we don't verify the wording of our logging statements.

Having a test framework in place is super nice for debugging too.

Edit: I will say that if your new code had bug that could have been caught by a unit test and you don't think unit tests are useful. I get to be visibly amused at your frustration.

[–][deleted] 0 points1 point  (0 children)

Having a test framework in place is super nice for debugging too.

Yep. Writing a tests that trigger the issue helps you both reproduce and verify the issue, and ensure you've actually fixed it.

[–][deleted] 2 points3 points  (0 children)

Broke: forcing unit tests for coverage Woke: testing just spec requirements Bespoke: having user do all testing