[morbidhawk]

I wish I could get to the bottom of this. I've seen all kinds of arguments for and against whether or not to unit test and how much / when unit testing should happen. I haven't been able to figure it out yet.

- I heard it mentioned before code reviews found more bugs in an experiment more than unit testing did (I heard this study was mentioned in Code Complete but I haven't checked the source on this). I wonder if reading code catches more bugs than writing code wouldn't this be an argument for spending more time reading our code rather than writing code that tries to understand it?

- Unit testing has the added benefit that when you change existing code or refactor you know that the behavioral unit tests guarantee those same behaviors happen after refactoring (my first point above doesn't give the same benefit so this may be worth a lot more than finding bugs in code reviewing new code (as it isn't reasonable to read all the existing code over again).

- I've also heard that code coverage is a terrible metric and can cause bad unit test practices, trying to cover all lines of codes instead of trying to test for specific behaviors.

- Some unit tests may become irrelevant as the design changes and also have maintenance costs

Since my team does unit testing while striving for 100% test coverage of our back-end web service code, we put a lot of time into unit testing (quality of the unit tests might be questionable sometimes as we aren't testing for all behaviors only ensuring all code is covered), so I wonder if we spent all the time that we spend unit testing and instead would read over all the code areas affected by the new code we and other teammates are writing to ensure we understand how it works, would it be more beneficial to read the code than to unit test it? I'm not convinced either way myself

[marvin]

I'm convinced, after working on a (micro)service-heavy 2+ million line code base for a couple of years now.

Our thousands of unit tests are invaluable, primarily for providing a strict definition of what the code should do, but also for catching bugs when refactoring. We don't often introduce bugs that break tests when refactoring simple parts of the system. But for the complex parts of the system, the tests both maintain a ground truth for how the code should behave, and make it trivial to ensure correct behavior after refactoring.

If we hadn't had the tests, we would be almost guaranteed to change the intended behavior of the code when modifying complex parts of the system. Perhaps no big deal if you're writing an Instagram clone and crashes will show up in your logs and prompt you to investigate, but critical when your code processes millions in financial transactions and subtle logging errors could cause a nightmare.

As always, it depends on your problem domain and priorities. There's an expensive overhead to having good test coverage. Many failed tests will be false positives.

[GrumpyYoungMan]

> I've also heard that code coverage is a terrible metric and can cause bad unit test practices, trying to cover all lines of codes instead of trying to test for specific behaviors. ... (quality of the unit tests might be questionable sometimes as we aren't testing for all behaviors only ensuring all code is covered) ...

Ugh, code coverage is _not_ a metric. Tell your team and your managers: "A high code coverage number is not the end goal; working code is the end goal." Code coverage simply tells you where you did and (more importantly did _not_) check for problems; the point is to consciously examine the code paths not covered and decide what unit tests are needed there, if any. It's perfectly fine for to say "This particular code does not need to be covered." or "This code path isn't practical to validate except in integration testing, therefore we'll forego a unit test and notify the QA team.", as long as the decision is reviewed and approved the same as one would do code review.