Here’s three quick thoughts on how you can/should work effectively in an environment that already has a lot of unit tests.
- When you find something missing, add tests
The thing about unit tests is that the best you can hope for, even with 100% coverage, is that the code is doing everything you could think of correctly. Which leaves everything you didn’t think of. The code might actually be totally wrong and your tests are simply verifying that it works the way you intended — which is not actually what is needed at all.
So when you find a case that isn’t working, use the TDD method — first write a test that fails, showcasing the thing that was overlooked, then fix it. Note, you might need to do this even if you are already at 100% coverage!
2. When reviewing test diffs be vigilant
If the tests had to change in the context of a diff that’s a sign that the observable behavior of the code has changed. This is a big deal! The last thing you want to do is simply adjust the tests so that they pass now, or delete an inconvenient test. Tests should only be deleted if the test was fundamentally wrong in that it was checking for something that shouldn’t have been true or cannot be assumed to be true (anymore).
3. When making changes, don’t just change the values to make the tests pass!
Every time the test values changed you have to think, “Why is the expectation changing now?” “Is the new value in fact correct?” “Do I really need to change ALL these values or are some of them not expected?”
The tests are very good at reporting what was observed vs. what was expected. If you just change the expectation to match the observation you’ve rendered the tests useless. If you’re reviewing, then you need to look at those changes to make sure they make sense. If you don’t understand then take the time to learn, or else get someone who does understand to look. Don’t just approve test changes “because test” and “it passes, so it must be right.”
Making tests pass is super easy… that’s not the point…