5 ms·

Is this about testing or unit testing? Personally one of the problems is that unit testing has such a hype train it leads to people using it always when it isn

by rb808 10y ago

Is this about testing or unit testing? Personally one of the problems is that unit testing has such a hype train it leads to people using it always when it isn't always necessary. With unit testing brings all the baggage: the DI, IoC containers, factories, mocks & all the stale test cases that were written a few years ago and no-one ever looks at but take 10 minutes to run. My current project has objects that are only ever used once in one place but still have abstract interfaces, lots of injected parts & test cases. Its only a simple class, it doesn't need all this extra complexity. For me its frustrating that lots of people think its "good design". Sure - you need to be able to test your application but unit testing everything is rarely the right way.

draw_down 10y ago
If you think that's bad, try inheriting a code base that has too few tests.
- morbidhawk 10y ago
  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
  - GrumpyYoungMan 10y ago
    > 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.
  - marvin 10y ago
    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.
alkonaut 10y ago
Unit tests are often the only spec there is. Code with no tests usually can't be rewritten/refactored without first making tests. They are significantly cheaper to write when the code is first created, than when the code needs to be refactored a decade later. DI/IoC aren't necessary (or aren't made necessary by unit tests). What tests do make is enforce small interfaces, and other good practices such as "Tell, don't ask" etc.

by rb808 10y ago

draw_down 10y ago

If you think that's bad, try inheriting a code base that has too few tests.

morbidhawk 10y ago
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
- GrumpyYoungMan 10y ago
  > 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.
- marvin 10y ago
  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.

alkonaut 10y ago

Unit tests are often the only spec there is. Code with no tests usually can't be rewritten/refactored without first making tests. They are significantly cheaper to write when the code is first created, than when the code needs to be refactored a decade later. DI/IoC aren't necessary (or aren't made necessary by unit tests). What tests do make is enforce small interfaces, and other good practices such as "Tell, don't ask" etc.