Do we test the Entitles independently or with the usecase, in clean architecture?

Viewed 83

I am trying to follow uncle bob's clean architecture. where he mentioned that the test is part of the system and we should consider it as an important part.

and the test should be decoupled from the system to enable it to evolve independently,

the way we do that is to provide the super API which forces the system in the testable state.

enter image description here

so, in the clean archetechure, we have the

  • Entities
  • usecase
  • UI

so, what is the way to implement the test in the system,

do we test suites for Entities and the Usecase?

or do we just test the Usecase and try to test the Entities indirectly?

and do we have to define the different sets to api just for testing, or should we use the input and output port of the usecase to test? if doing this way would it make the test too dependent on the system, and make it frazile?

1 Answers

so, what is the way to implement the test in the system,

do we test suites for Entities and the Usecase?

or do we just test the Usecase and try to test the Entities indirectly?

You usually test the entities as well as the use cases. Both contain logic that needs to be tested. Sure you also test the entities indirectly through the use cases. But if a use case test fails it might be hard in some situations to guess the cause. In those situations you wish you had written a unit test for the entities that show you if there is a problem in the entities or not.

As I said before "Both contain logic...". That's true as long as your entities are domain objects that contain domain logic. Some developers prefer an anemic programming style. In this cases the entities are just plain data structures and thus unit test only have a little benefit.

and do we have to define the different sets to api just for testing, or should we use the input and output port of the usecase to test?

You don't need a different api. You just replace the interface adapters layer. I found some diagrams that might make it clear. These diagrams are taken from a presentation that I did some time ago

So what you basically do is to turn this production setup

production setup

into this test setup

test setup

PS: Some time ago I made a presentation for a team with a hexagonal architecture background and the diagrams above are taken from that presentation. That is the reason why I used the hexagonal visual representation of the application core. But I guess it can be easily applied to the clean architecture.

I also omitted the layers within the application core, because I focus on the outside.

Related