3 ms·

I had the opposite experience. One of the many good practices unit testing encourages is encapsulation. With encapsulation and mocking during testing, there i

I had the opposite experience. One of the many good practices unit testing encourages is encapsulation. With encapsulation and mocking during testing, there is very little chance of a cascade affect when changing a method or doing some refactoring.

eesmith 7y ago
The question is, what's the encapsulation level? If you only change the internals of a method, then it's clear that the method call is the API. But the specific method calls are rarely the deliverable (outside of library packages). Those are usually much higher, eg, web API or command-line options. Instead, the methods can be rather fluid. My experience is that the "unit testing with small methods" approach usually emphasizes testing each method. The analogy I use is that of building a bridge, where you don't care what sort of bridge is made, only that it can handle a specific amount of traffic. So I build a truss bridge, with tests that each of the struts is correct. But this is programming, and I decide it's better to replace the truss with a suspension bridge, so I do that. Which means I have to throw away all the strut tests, since I don't have them. While if I had only used load tests from the start - integration tests for what the customer actually wants - then I could do wholesale rewrites without changing much of the tests.
- Consultant32452 7y ago
  I want to be clear I'm not disagreeing with you here. But I would like to point out if you were building a real bridge every component would be inspected individually. They wouldn't just let you build a whole bridge and do a final load test. Whether that level of robustness/ confidence is important will be highly contextual.
  - eesmith 7y ago
    Yes, and part of the mythos of unit testing - especially around small methods - is based on that real-world analogy, when "this is programming", and many of the rules are quite different. As another analogy, if you breadboard a device you can test each individual component directly. Once it's on a chip, most of those individual tests can no longer be used. That's not to say they can't be tested, only that the testing must be done on a higher interface level. So, do you use those higher-level tests, which are more like intergration tests, or do you write the low-level unit tests and expect to throw the away at any sort of non-trivial code changes?

eesmith 7y ago

The question is, what's the encapsulation level? If you only change the internals of a method, then it's clear that the method call is the API. But the specific method calls are rarely the deliverable (outside of library packages). Those are usually much higher, eg, web API or command-line options. Instead, the methods can be rather fluid. My experience is that the "unit testing with small methods" approach usually emphasizes testing each method. The analogy I use is that of building a bridge, where you don't care what sort of bridge is made, only that it can handle a specific amount of traffic. So I build a truss bridge, with tests that each of the struts is correct. But this is programming, and I decide it's better to replace the truss with a suspension bridge, so I do that. Which means I have to throw away all the strut tests, since I don't have them. While if I had only used load tests from the start - integration tests for what the customer actually wants - then I could do wholesale rewrites without changing much of the tests.

Consultant32452 7y ago
I want to be clear I'm not disagreeing with you here. But I would like to point out if you were building a real bridge every component would be inspected individually. They wouldn't just let you build a whole bridge and do a final load test. Whether that level of robustness/ confidence is important will be highly contextual.
- eesmith 7y ago
  Yes, and part of the mythos of unit testing - especially around small methods - is based on that real-world analogy, when "this is programming", and many of the rules are quite different. As another analogy, if you breadboard a device you can test each individual component directly. Once it's on a chip, most of those individual tests can no longer be used. That's not to say they can't be tested, only that the testing must be done on a higher interface level. So, do you use those higher-level tests, which are more like intergration tests, or do you write the low-level unit tests and expect to throw the away at any sort of non-trivial code changes?