Timeline for Do unit tests sometimes break encapsulation?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 20, 2020 at 17:03 | comment | added | wcochran | I am in a situation where I have a public method named reconstruct() that invokes a sequence of complex computer vision tasks which are private. The correct thing to do is to unit test each complex task -- unit testing just the public method is not granular enough. I want to make sure each internal task does its job correctly. I don't believe I am doing it wrong. | |
| Oct 22, 2012 at 1:13 | comment | added | user1288851 | Well, from my perspective it sometimes does. If you are splitting things that change together, thas is a clear violation of SRP. On the other side, if you are splitting two concerns, then you are actually enforcing encapsulation taking the acess of implementation details on B out of A. But it really depends from case to case. My problem is (or was, rather) that if one thing in that class changes, everything in that class needs to change, so it is a cohesive and SRP-friendly class. But it is still too hard to test alone. | |
| Oct 21, 2012 at 15:35 | comment | added | Andres F. | +1 Factoring class B out of class A doesn't break the encapsulation of the API for A. Clients of A still don't have to know B; you simply added testing for B. | |
| Oct 21, 2012 at 11:11 | history | answered | Landei | CC BY-SA 3.0 |