How to test a method which is not as much as a unit, because it is more of a 'orchestrator' / 'process' / 'controller' / 'coordination' class [duplicate]

Question

I want to test a method which is not as much as a unit, because it is more of a 'orchestrator' / 'process' / 'controller' / 'coordination' class.

This is the case:

I have four unit tested classes:

• One is a data service which can read/write data from the database
• Second is a textservice which can create content for emails / messages etc.
• Third is a mailservice that can send email
• Fourth is a class dat can create tasks for users in our system (tasks are things they should do)

Now I created a new class, which sends an email all people which are late with paying an invoice. It reads data with the data service, creates the appropriate text with the textservice, sends an email with the email service, writes the new invoice status with the data service and creates a task when the emailing for a specific invoice fails.

Now this new class is my 'orchestrator' or 'process' or 'controller' or 'coordination' class.

I have these kind of classes a lot in our application because we try to make our classes (like the data/email/textservice) as small as possible so when 'work has to be done', like in this case the 'mail all people which are late with paying', we create a new 'orchestrator' or 'process' or 'controller' or 'coordination' class.

I think I have these kind of classes for the most of my actions in my webcontrollers because most input sent from the browser involves coordination between multiple (smaller) classes

Now how do I test these classes / methods?

I used to mock all 4 classes in my test and verify at the end that the classes are called, and in the right order.

But more and more I read that you shoud not do this, because then you test for the internal working of a method, and when you refactor that method, the test fails. So I should test for results, not for inner working. But this method is void, so there is nut much of a result to verify on. The only thing I can think for instance to check for is: is email sent? But the only way to check that is to verify the email service is called, but then I'm back at testing the internals.

I don't see these kind of examples in the unit testing / tdd books, because they most of the time only work with the small classes like the calculator class, but rarely do I see examples for 'orchestrator' classes like I'm describing, but which occur a lot in my code.

For those who think it's a duplicate: I think the answers here provide much more background than the one answer at the other question. That other question was answered with a integration test in mind, and my question is about unit testing, not integration testing. So I can't agree with the duplicate answer mark.

Answer 1

From what you describe I would say that the way you have been doing it - mocking the collaborators - is the best approach. It may be that you are over-specifying with your mock - for instance, requiring an order which is not really required by the business needs; if that is the case you could lighten up on the order requirements of your tests. But basically for the coordinator you want to know that:

• given a data service who says "these people are late"
• given a text service which generates email of the form "hey, you're late"
• given an email service which sends to a list of recipients
• it will submit a request to the email service to send "hey, you're late" to the aforementioned set of people.

If it's doing that (and a few other things you mentioned which I'm not bothering to re-specify here), then as far as you're concerned, your coordinator class is working. That's an easy test to write with mocks, clean and communicative. That's the way I'd recommend.

Answer 2

It is absolutely not the responsibility of your coordinator to send mail, only to ask that it be sent. There are many reasons why a mail might not be sent, or delayed. It is the responsibility of your mail class to

1. send valid mail
2. reject invalid mail
3. Log what it did (including unexpected failures to send valid mail)

All your coordinator has to do, with regard to mail, is

1. Ask for mail to be sent
2. React appropriately if the call to the mail object returns a failure.
3. Log what it did

If your tests for your mail class are comprehensive, you should be confident that valid mail requests will be sent and problems logged. If, for some reason, your coordinator can create problem emails, this will become apparent very quickly in use and you will have all the data you need from the logs to fix the problem. Please be relaxed about that; there is no way to create tests which guarantee no failure ever. Content yourself with tests that test a components contract and that show the class always behaves responsibly both when a request honours the contract and when it breaks it.

It is important that components be testable in isolation. If testing one component requires that others be fully present, then they really are not separate components and you risk creating one big ball of mud. It is actually more dangerous than mocking, because you risk the creation of hidden dependencies on implementation details of those other components. It also means that any internal changes to those components force an update to the build and test process for this one. That scales terribly and wastes everybody's time.

Don't import any logic from the mail class into the mock. Please do test for both success and failure of the mail class, but make those arbitrary events, not something using logic copied from the real class into your mock. It is a waste of time and reintroduces the risk of hidden dependencies on implementation details.

Build your system cleanly based on these principles. Trust the system. Don't complicate it into a mess because you want it to prove in each part that the whole system works. That will fail and make failure more likely.

tl;dr

The law of Demeter applies to testing as well.

Answer 3

I don't think there is anything else that you can do except testing that the functions inside that method are called.

Since the "orchestration" method doesn't contain much logic unit-testing is not so important. It's a method that only wires up other methods. It integrates other components. Therefore there should be integration tests that cover those lines of code. Unit tests may be omitted. So I wouldn't worry about it too much as long as you have those integration tests. Though, how this can be integration tested is another topic because you should not mock all of the other components and therefore get some dependencies that you are going to have to deal with.

Answer 4

You generally don't need to test controller classes, since they shouldn't hold complex logic. The actual work should be done in other classes if it is written correctly, so in the end you're essentially ensuring that the work gets delegated correctly.

The complexity of this depends entirely on the language that you're using, since to do it correctly, you would need to create stubs. Languages like Java might have a hard time with this, but there are libraries that help you with this like Mockito.

If you do need to test your controller class, then you should ideally remove the surrounding classes and put stub classes in their places, then you simply verify that the proper method gets called in response to each input to your controller class. I remind you that the whole point of unit testing is to verify that each method is doing its job properly. For a controller class, that generally means delegating tasks properly.

The alternative to using stubs would be to perform the actual work, though this can easily get overwhelming to test given the complexity and other complications such as writing to the database, so I would advise against it.

Also, I would strongly advise you to extract only the information required in web controller classes and pass it to the methods that do the logic. The reason for this is that you don't have to mock http request and response objects, but only what you pass, and you shouldn't have to test a method that dumbly retrieves the data required and passes it to another method (if it passes a null value, fine, don't test any more than you have to).

I hope that helps!