12 ms·
I prefer the first example. It’s more straightforward and avoids accidentally creating dependencies (for example some other code calling pluck_definition) that
by zeroonetwothree 6y ago
I prefer the first example. It’s more straightforward and avoids accidentally creating dependencies (for example some other code calling pluck_definition) that will be make it harder to modify when you need to add features or the API changes.
Testing pluck_definition by itself is completely pointless since it does nothing on its own. This is the “test public interfaces, not private implementation” principle.
Similarly build_url and pluck_definition need to be coupled because they both depend on the specifics of a third party API. It makes it much more clear what the expected output is to keep them together so that if something breaks you know which url to check and what the response should look like.
I also dispute that it’s hard to unit test the first function—-you would simply mock the api response and then you have a great test. Much better than having separate tests for tiny helper functions that do nothing on their own.
Now maybe this example is just too simple and the presented architecture makes more sense on larger code but if so then the article is poorly written. Examples need to be realistic enough not to obfuscate.
- acdha 6y ago> I also dispute that it’s hard to unit test the first function—-you would simply mock the api response and then you have a great test. How many times have you seen a test pass or fail when it shouldn’t have because the mocks didn’t match the actual code? It’s a useful technique but it has drawbacks which are not easily prevented.
- yeswecatan 6y agoYou would still need to use mocking to test the imperative shell
- danuker 6y agoThis, here, is what I meant!
- jakeva 6y agoWe use mocks a lot on my team, and I don't think we've ever seen what you describe. Maybe you're using mocks incorrectly?
- acdha 6y agoYou might also want to consider the possibilities that you have problems but haven't noticed them yet or that your experience is not a global truth applicable to all projects. If you think about the problem more, ask yourself how it's possible to mock a remote HTTP call without the risk of this problem? I've seen people write frameworks which periodically save and cache responses but unless you regularly perform some kind of validation there's no way to avoid that problem.