6

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.

luistm
  • 163
  • 5

1 Answers1

4

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.

candied_orange
  • 119,268