5 ms·

I admit I still haven't really latched onto unit testing. I gave it an honest effort about a year ago, but the amount of time I was spending to mock out the inp

I admit I still haven't really latched onto unit testing. I gave it an honest effort about a year ago, but the amount of time I was spending to mock out the inputs and then actually writing the test was absurd and I didn't feel provided enough benefits for the time out took me away from "productive" coding. Maybe I'm doing it wrong, who knows...

notacoward 7y ago
Maybe, but there are a couple of more likely explanations. (1) You're working on a system that is poorly structured for testing. (2) You're trying to make a unit test do an integration test's job. Both are incredibly common. In particular, if you find that you're spending a lot of time creating mocks/stubs to support unit tests you'd probably be better off finding a way to inject errors in an integration test. Error injection can be done at any level, works even when the code structure makes mocking difficult, and exercises code paths that cross multiple components in their "final" close-to-production form. IMX most of the people who go crazy about unit tests just haven't thought deeply enough about the problem to realize that error injection is strictly better (and a lot easier) most of the time.
- JoeAltmaier 7y ago
  There's quite a bit of "no true Scotsman" in there? If few get 'unit testing' right, then I believe there may actually be something wrong with it, not just a failure to 'do it right'. Mocking is for exercising all inputs to a method, not just error injection. In fact that's fundamental to unit testing, and a necessary part. And it can grow to become a nightmare.
  - notacoward 7y ago
    > There's quite a bit of "no true Scotsman" in there? Only in your head. I'm not trying to claim unit tests aren't useful, or that any particular unit tests aren't good. The only fallacy in sight here is strawman. > Mocking is for exercising all inputs to a method How useful is that if they're values that the real version of the mocked component can never return? As I said right at the start, this kind of validation has value when changing code later, but that's a lower priority than validating that the whole system as it is today does what it's supposed to. Doing unit tests right is valuable, but is much more of an art than most people realize. A good unit test should cover inputs and paths well, but not constrain implementations. Most unit tests I've actually seen - quite a lot BTW - are the exact opposite. People need to stop thinking in terms of depth (adding mock after mock and implementation-specific check after check for a few obvious scenarios) and think in terms of breadth (lighter weight validation of more scenarios) instead. P.S. If your "inputs" are results from functions that have to be mocked for testing, it's often a sign that the code has a backwards control flow. When that happens, it's better to fix the control flow than to add more mocks.
- justanotherc 7y ago
  #1 is very likely. However if it is extremely common to do unit tests "wrong", then that would mean I would need to find a testing guru to learn from in order to do it "right", and do a great deal of study to learn myself. The possibility of that happening is very low. Does this not give credence to the notion that there may in fact be something wrong with unit testing in general? Is it not just compounding the problem? I'd rather spend my limited cognitive currency and time in the system itself, not in mastering the art of unit tests... Unit testing should be a tool not an art. If a tool doesn't simplify my life, it has limited utility.
  - notacoward 7y ago
    I don't exactly disagree with you. I've been on many projects where unit tests failed to justify the time spent writing them (including mocks) and dealing with spurious failures. I believe they can be beneficial, but only if people understand their limitations and play to their strengths. I'll gladly use them to vet code that implements a completely self-contained data structure or algorithm with no dependencies, and I've done so to good effect many times. Otherwise, I'd rather write a proper stub/simulator that can be used in integration tests to exercise multiple components at once than waste time with single-purpose mocks. > I'd rather spend my limited cognitive currency and time in the system itself, not in mastering the art of unit tests That's not quite an either/or. Over an entire career you'll probably work on many systems each requiring their own specific knowledge. Knowing one system is great as long as you're working on that system, and mostly useless thereafter. Knowledge of how to write good tests (unit or otherwise) is much more transferable. Every team can use somebody with those skills.

notacoward 7y ago

Maybe, but there are a couple of more likely explanations. (1) You're working on a system that is poorly structured for testing. (2) You're trying to make a unit test do an integration test's job. Both are incredibly common. In particular, if you find that you're spending a lot of time creating mocks/stubs to support unit tests you'd probably be better off finding a way to inject errors in an integration test. Error injection can be done at any level, works even when the code structure makes mocking difficult, and exercises code paths that cross multiple components in their "final" close-to-production form. IMX most of the people who go crazy about unit tests just haven't thought deeply enough about the problem to realize that error injection is strictly better (and a lot easier) most of the time.

JoeAltmaier 7y ago
There's quite a bit of "no true Scotsman" in there? If few get 'unit testing' right, then I believe there may actually be something wrong with it, not just a failure to 'do it right'. Mocking is for exercising all inputs to a method, not just error injection. In fact that's fundamental to unit testing, and a necessary part. And it can grow to become a nightmare.
- notacoward 7y ago
  > There's quite a bit of "no true Scotsman" in there? Only in your head. I'm not trying to claim unit tests aren't useful, or that any particular unit tests aren't good. The only fallacy in sight here is strawman. > Mocking is for exercising all inputs to a method How useful is that if they're values that the real version of the mocked component can never return? As I said right at the start, this kind of validation has value when changing code later, but that's a lower priority than validating that the whole system as it is today does what it's supposed to. Doing unit tests right is valuable, but is much more of an art than most people realize. A good unit test should cover inputs and paths well, but not constrain implementations. Most unit tests I've actually seen - quite a lot BTW - are the exact opposite. People need to stop thinking in terms of depth (adding mock after mock and implementation-specific check after check for a few obvious scenarios) and think in terms of breadth (lighter weight validation of more scenarios) instead. P.S. If your "inputs" are results from functions that have to be mocked for testing, it's often a sign that the code has a backwards control flow. When that happens, it's better to fix the control flow than to add more mocks.
justanotherc 7y ago
#1 is very likely. However if it is extremely common to do unit tests "wrong", then that would mean I would need to find a testing guru to learn from in order to do it "right", and do a great deal of study to learn myself. The possibility of that happening is very low. Does this not give credence to the notion that there may in fact be something wrong with unit testing in general? Is it not just compounding the problem? I'd rather spend my limited cognitive currency and time in the system itself, not in mastering the art of unit tests... Unit testing should be a tool not an art. If a tool doesn't simplify my life, it has limited utility.
- notacoward 7y ago
  I don't exactly disagree with you. I've been on many projects where unit tests failed to justify the time spent writing them (including mocks) and dealing with spurious failures. I believe they can be beneficial, but only if people understand their limitations and play to their strengths. I'll gladly use them to vet code that implements a completely self-contained data structure or algorithm with no dependencies, and I've done so to good effect many times. Otherwise, I'd rather write a proper stub/simulator that can be used in integration tests to exercise multiple components at once than waste time with single-purpose mocks. > I'd rather spend my limited cognitive currency and time in the system itself, not in mastering the art of unit tests That's not quite an either/or. Over an entire career you'll probably work on many systems each requiring their own specific knowledge. Knowing one system is great as long as you're working on that system, and mostly useless thereafter. Knowledge of how to write good tests (unit or otherwise) is much more transferable. Every team can use somebody with those skills.