If you end up in such situations, your classes are probably too big and try to do too much in one thing.

sent from a mobile device so please excuse strange words due to autocorrection.
Peter Sommerlad
peter.cpp_at_[hidden]
+41-79-432 23 32

> On 6 Dec 2020, at 21:20, chibane nadir <organicoman_at_[hidden]> wrote:
>
> @Peter: usually it is true to avoid testing private members, but for the sake of preventing a subsequent refactor of public API from creating side effects on private members, we need to create test cases with the purpose of fixing invariant in our classes. Also if you look at it in different manner, private members are part of the logic of the classes, which means not testing them could create logic bugs (what i call smart bugs) and refactoring them into public member would expose a lot of the guts of the implementation.
>
> I used to test private members by checking their effects on public members (transitive side effects), but i run into a lot of cases where you cannot pin point the effect of a private member if the public member depends on many of them.