4

After reading the last book from Robert C. Martin, I've tried a to develop some big Go applications following clean architecture. While writing interactors, I end up with a lot of complex unit tests, because the interactor has a lot of external dependencies.

What are the best practices for testing the interactors? Should I test the happy path only using an integration test? Using unit tests in the interactor I end up with a lot of mocks, it's not something I'm happy about.

Any advice or comments on this?


One of the applications on which I'm working is this one: https://github.com/luistm/banksaurus . It's far from great, but it's mostly a playing ground.


The first conclusion I get from this question is that one must understand the difference between Mock, Fake and Stub.

  • What do you mean by "complex" unit test. What do you mean "lot of " dependencies? Did you try using fakes instead of mocks? – Euphoric Apr 2 '18 at 5:47
  • Would you mind to copy here an example of one of these "bloated" interactors and its unit test? No need to copy all the classes involved. For the sake of the question, avoid to use meaningless names like Foo, Bar, X, A. You can leave the class, methods and var names as they are. – Laiv Apr 2 '18 at 7:40
  • You can see an example here: github.com/luistm/banksaurus/blob/master/bank/transactions/… . I really don't like the way this is done. – luistm Apr 2 '18 at 14:11
  • Doesn't go's testing framework have something similar to NUnit's TestCase? Because it seems you are replicating that functionality inside your tests. Another thing I recommend trying is faking, not mocking, the dependencies. My experience is that faking produces much simpler test code than mocking. – Euphoric Apr 2 '18 at 15:11
  • What Euphoric is saying, correct me if I'm wrong, is: use stubs instead of mocks – Laiv Apr 2 '18 at 17:55
3

While writing interactors, I end up with a lot of complex unit tests, because the interactor has a lot of external dependencies.

Really?

enter image description here

The controller passes you a request model, you build a response, after talking to some entities, and send that to a presenter. That shouldn't be a complex unit test because any one interactor shouldn't be doing anything more complex than that. I don't see any dependencies here that must be external.

You shouldn't only test the happy path. 80% of coding is dealing with things gracefully when they go wrong. But stick to fixing problems that can actually be caused.

Using unit tests in the interactor I end up with a lot of mocks.

Man I wish I knew exactly what you meant when you say mocks but whatever kind of test double you use, don't use it to test things no one cares about. You could make all sorts of crazy tests by making your own test entities with asserts in them I'm sure but what we care about here is sending the right response model to the right presenter. If you're testing more than that I don't know why.

  • But for instance, should I test that I can deal with every error? Should I test that when you pass data to the presenter, it can return an error? Looks like a lot of tests to do in the interactor. Maybe I should unit-test every function and just write some happy path integration test to the interactor. That's my feeling right now. – luistm Apr 3 '18 at 7:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.