4 ms·

If that is a simple 10 line script, I agree. But if that is part of an application, you will not be able to properly test it - so you either have to do time con

If that is a simple 10 line script, I agree. But if that is part of an application, you will not be able to properly test it - so you either have to do time consuming manual tests or time consuming integration tests. Splitting it into different parts allows to write unit tests and smaller integration tests. Then, when you only change the "pure" parts, you only have to verify the unit tests. That gives a HUGE productivity boost in bigger applications.

MeteorMarc 6y ago
You only want to test on public API, because else you cannot change the implementation without adapting your perfect unit test on implementation details. So, I prefer the first code example and do not mind some mocking (unless the extracted functions make sense on the public API).
- winkeltripel 6y ago
  A large application has lots of implementation leak to the API, doesn't it?
  - Izkata 6y ago
    For this reason, when mocks are involved (that is, just about any external API), I think Listing 2 is the ideal - extract a small function designed around the desired interface, a facade that's easily mockable and won't change with the library implementation.
- valenterry 6y ago
  If you take that idea/ideal to the very logical end, then you can only do system tests / acceptance tests (however you want to call it). Your tests must only be able to do what end-users do - everything else would be relying on implementation details. No unit tests at all! ...unless we take a more compositional approach and define our application to consist of many "parts" each of which has a public API and an implementation. Well, in that case I would argue that each function can be considered as such a part, having a public API (the definition of its inputs and outputs) and an implementation that can be changed while keeping the public API stable. Over the time I came reached a conclusion: whenever I have to run some code to be sure it does what it should, I write a test instead. And every often that is a unit test. If I'm highly confident that the code will do what I expect, then I rely on very high level system tests, unless I fear that someone might break the code later by accident without the compiler (or other existing tests) being able to detect that.

MeteorMarc 6y ago

You only want to test on public API, because else you cannot change the implementation without adapting your perfect unit test on implementation details. So, I prefer the first code example and do not mind some mocking (unless the extracted functions make sense on the public API).

winkeltripel 6y ago
A large application has lots of implementation leak to the API, doesn't it?
- Izkata 6y ago
  For this reason, when mocks are involved (that is, just about any external API), I think Listing 2 is the ideal - extract a small function designed around the desired interface, a facade that's easily mockable and won't change with the library implementation.
valenterry 6y ago
If you take that idea/ideal to the very logical end, then you can only do system tests / acceptance tests (however you want to call it). Your tests must only be able to do what end-users do - everything else would be relying on implementation details. No unit tests at all! ...unless we take a more compositional approach and define our application to consist of many "parts" each of which has a public API and an implementation. Well, in that case I would argue that each function can be considered as such a part, having a public API (the definition of its inputs and outputs) and an implementation that can be changed while keeping the public API stable. Over the time I came reached a conclusion: whenever I have to run some code to be sure it does what it should, I write a test instead. And every often that is a unit test. If I'm highly confident that the code will do what I expect, then I rely on very high level system tests, unless I fear that someone might break the code later by accident without the compiler (or other existing tests) being able to detect that.