4 ms·

How do you handle dependencies of the class under test then?

by efdee 9y ago

scruple 9y ago
Would love an answer to this question, as well. I've only come up with DI as a long-term mostly win for this problem and it's something that I grapple with in every code base at work, since we have some microservices and other HTTP API layers that we need to interface with and I want to write testable code.
rasmus4200 9y ago
This is the biggest challenge. What I find works is separating your orchestrations from your data processing. For example, instead of creating one class that does the network call, and processes the JSON response, break these out. One class does the network call (keep it extremely thin). Dependency inject stuff in if you want. But view this purely as an orchestration. if (connectionValid) json = makeNetworkCall anotherObject.processJson(json) <- test separately end Then, in the other plain old data process class, do you heavy off-by-one edge case testing there. If the first case, the orchestration, I can write tests like "One make the network call if the connection is valid". But that's all that test would do. I am at the point now where I actually don't even test that. I assume that is going to work, because it is so simple. That and I generally hate mocking. Way too much coupling. Way too hard to refactor. Where I do test heavy is on the plain old object side, that has no outside ports or connectors. These are just plain old objects. I agree with some other comments I have ready here. Mocking is a bitch and I generally don't like it. But it's there if I needed it, so I do use it occasionally. But it has so many downsides I try not to. Instead I separate the orchestrations from the processing. Unit test the processing (in an integration test sort of way), and try to stick to testing the public APIs of my class, so I am free to change the internals without things breaking. My 2c. Hope that helps.

How do you handle dependencies of the class under test then?

by efdee 9y ago

How do you handle dependencies of the class under test then?

Would love an answer to this question, as well. I've only come up with DI as a long-term mostly win for this problem and it's something that I grapple with in every code base at work, since we have some microservices and other HTTP API layers that we need to interface with and I want to write testable code.

rasmus4200 9y ago

This is the biggest challenge. What I find works is separating your orchestrations from your data processing. For example, instead of creating one class that does the network call, and processes the JSON response, break these out. One class does the network call (keep it extremely thin). Dependency inject stuff in if you want. But view this purely as an orchestration. if (connectionValid) json = makeNetworkCall anotherObject.processJson(json) <- test separately end Then, in the other plain old data process class, do you heavy off-by-one edge case testing there. If the first case, the orchestration, I can write tests like "One make the network call if the connection is valid". But that's all that test would do. I am at the point now where I actually don't even test that. I assume that is going to work, because it is so simple. That and I generally hate mocking. Way too much coupling. Way too hard to refactor. Where I do test heavy is on the plain old object side, that has no outside ports or connectors. These are just plain old objects. I agree with some other comments I have ready here. Mocking is a bitch and I generally don't like it. But it's there if I needed it, so I do use it occasionally. But it has so many downsides I try not to. Instead I separate the orchestrations from the processing. Unit test the processing (in an integration test sort of way), and try to stick to testing the public APIs of my class, so I am free to change the internals without things breaking. My 2c. Hope that helps.