Timeline for In Clean Architecture, aren't Entities another type of Boundary?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 19, 2018 at 13:08 | comment | added | Pierre Criulanscy | This video explains it very well : TDD, Where Did It All Go Wrong | |
| Dec 19, 2018 at 13:04 | comment | added | Pierre Criulanscy | @FernandoToigo I didn't say that you should serialize your entities, you should not. Entities are just business logic and shouldn't be tied to any specific persistence mechanism. It all boils down to what you define by "unit". You don't want to test the methods of your entities alone, because it's mostly an implementation detail. The "unit" you want to test is a whole behavior that you can phrase like this : given some initial state, when something occurs, then something should have happened / some state should be "this" or "that". | |
| Dec 19, 2018 at 11:13 | comment | added | Fernando Toigo | @PierreCriulanscy I want to test every unit independently and I don't want to have unit tests of various interactors failing because of changes on an specific entity. I want just the unit tests of the changed entity to fail (along with integration tests). About your second comment, I see a bigger problem with that. I don't think your entity class (which holds business logic) should be the class that is going to be serialized. You probably need another class for that (which in turn should have agnostic identifiers). | |
| Dec 19, 2018 at 9:12 | comment | added | Pierre Criulanscy | @FernandoToigo And, by the way, you're not supposed to access other entities directly from your entity. You declare dependencies between your entities through their identifiers. Yes, it leaks some technical details, but it's better than depending directly on your entities, because in that case, you're tied to a specific type of persistence, and you entities are going to be lazy loaded via some kind of ORM, defeating the purpose of DDD (but some people advocates for this practice, so it's up to you). | |
| Dec 19, 2018 at 9:01 | comment | added | Pierre Criulanscy | @FernandoToigo You're supposed to access your entities only via the aggregate root. Entities can access their value objects to delegate some behaviors, you never need to mock your entities since that's what you want to test. Maybe you're struggling with what to test in the first place. | |
| Dec 18, 2018 at 20:49 | history | edited | Robert Harvey | CC BY-SA 4.0 |
deleted 20 characters in body
|
| Dec 18, 2018 at 19:43 | comment | added | Fernando Toigo | But what if the Entity that is being used in my Interactor is using others entities? This might become troublesome to test the Interactor, as its dependencies cannot be mocked. | |
| Dec 18, 2018 at 19:30 | history | edited | candied_orange | CC BY-SA 4.0 |
added 2 characters in body
|
| Dec 18, 2018 at 16:52 | comment | added | Walfrat | I think this might need to be a bit more accurate. While I do not know clean architecture. I think that while you might execute entities code, you will only write and executes tests which will check that your applications rules are correctly implemented. Of course if you're also happens to be developping also the entities layer, you will test business rules, but not in the same place than your application specific ones. | |
| Dec 18, 2018 at 15:44 | history | edited | Pierre Criulanscy | CC BY-SA 4.0 |
deleted 1 character in body
|
| Dec 18, 2018 at 14:21 | history | answered | Pierre Criulanscy | CC BY-SA 4.0 |