"if I test through one class as entry point, I don't have to change tests if something internal changes". Not really. By actually having this huge SUT, you're coupling setups of all of the tests you have (for all of the use cases you're testing). If you change arrange for one use case, you'll have to change arrange parts in all other test cases, that even though test different use are coupled to the other classes which you also need to setup in order to test just this small functionality you wanted to test. The whole reasoning behind small SUTs is that they're focused, can pinpoint exactly where's the problem when the test fails (unlike big SUT) and tests for these small SUT are decoupled from tests for other small SUTs. You want to have larger scope/SUT tests, in order to prove that the wire up is good, but those should as well follow Mike Cohn's test pyramid and be lot less percentage than the tests for a small SUT.
"single public class easier to test because you have one entry point". Not really. The bigger the SUT (iceberg shape in this case), the more permutations you have to test cause you enter all of the test cases through a single point and the harder it is to setup a test (Arrange part), cause you have to instantiate N classes just to test one small part of the behavior. Same thing why you wouldn't test a whole system end to end, but you test it component/service by service (putting aside the slowness of end to end tests as one of the other problems)
From my practical experience of using this method over 3+ years, even if a bounded contexts (module, SUT) is relatively large, there is no problem with number of permutations (or complexity), as the boundary (interface) is simple and clearly defined. If your bounded context (module, SUT) has more behaviours than you can handle, perhaps it should be smaller? But of course it much depends on how you do your architecture, so your milage may vary.
The arguments are driven from experience of using it for year. I'm describing what worked for me and my teams. This is not a theoretical work. It may or may not work for you, but you'll not know it until you try.
Very insightful video. Thank you Jakub!
is there a link to github for a reference architecture example
?
github.com/jakubnabrdalik/hentai
"encapsulation says hide everything you can". Well, not really.
Information hiding is different from encapsulation
air shoulder fist at 00:00 :D
"if I test through one class as entry point, I don't have to change tests if something internal changes". Not really. By actually having this huge SUT, you're coupling setups of all of the tests you have (for all of the use cases you're testing). If you change arrange for one use case, you'll have to change arrange parts in all other test cases, that even though test different use are coupled to the other classes which you also need to setup in order to test just this small functionality you wanted to test. The whole reasoning behind small SUTs is that they're focused, can pinpoint exactly where's the problem when the test fails (unlike big SUT) and tests for these small SUT are decoupled from tests for other small SUTs. You want to have larger scope/SUT tests, in order to prove that the wire up is good, but those should as well follow Mike Cohn's test pyramid and be lot less percentage than the tests for a small SUT.
"single public class easier to test because you have one entry point". Not really. The bigger the SUT (iceberg shape in this case), the more permutations you have to test cause you enter all of the test cases through a single point and the harder it is to setup a test (Arrange part), cause you have to instantiate N classes just to test one small part of the behavior. Same thing why you wouldn't test a whole system end to end, but you test it component/service by service (putting aside the slowness of end to end tests as one of the other problems)
I see you missed the point since DDD and Bounded Context has nothing to do with this; and interesting to see that you have some years to grow up :)
From my practical experience of using this method over 3+ years, even if a bounded contexts (module, SUT) is relatively large, there is no problem with number of permutations (or complexity), as the boundary (interface) is simple and clearly defined. If your bounded context (module, SUT) has more behaviours than you can handle, perhaps it should be smaller?
But of course it much depends on how you do your architecture, so your milage may vary.
I appreciate the effort to prepare and make this talk, but unfortunately the arguments are very weak and driven from the other way around.
The arguments are driven from experience of using it for year. I'm describing what worked for me and my teams. This is not a theoretical work. It may or may not work for you, but you'll not know it until you try.