How should I unit test methods with lots of DOC's (depended-on code)?

Let's say we have a method that mostly wires together various other methods; doesn't do a whole lot of its own logic. Let's say it's a typical member of a service class in a Service Layer, calling methods in domain model (business) classes, data开发者_如何学Go access classes, and an email utility / service class.

I'm finding that writing a true unit test for this method requires lots of test double setup, and there's very little logic being tested here. It seems like the cost is going to outweigh the value if I continue this way. What should I do?

---

You shouldn't have more than one mock per unit test. From The Art of Unit Testing by Roy Osherove (p. 94):

In a test where you test only one thing (which is how I recommend you write tests), there should be no more than one mock object. All other fake objects will act as stubs. Having more than one mock per test usually means you’re testing more than one thing, and this can lead to complicated or brittle tests.

Here is a related stack overflow question that may be of help.

---

I'm not a purist when it comes to unit tests. There is a point of diminishing returns, where the cost to create and maintain a given test is conceivably greater than the benefit you will receive from executing that test. However there is no hard and fast rule as to where that point exists.

I have opted to write unit tests for code similar to what you described. However in most of those cases I made sure that the underlying objects (which you would be mocking) have appropriate unit tests running against them. However in cases where there is a significant amount of internal logic, unit testing is still definitely the order of the day.

I don't think there is a right answer to this question, but hopefully my comments below help your thought process on how and whether you should unit test this.