Date: Mon, 7 Dec 2020 17:51:21 +0000 (UTC)
I think this is a nice pattern.I don't know how i missed it!! I will use it definitely.Just one comment about existence, i proposed to make a friend namespace just for this concern.
Thanks All for the nice discussion.
Le lundi 7 décembre 2020 à 17:46:40 UTC+1, Gašper Ažman <gasper.azman_at_[hidden]> a écrit :
+1 to what Peter said, but unfortunately the vast amounts of legacy code that one has to put unit tests around *before* refactoring it (not to mention get the refactor funded) mean that we have to have semi-clean techniques of doing stuff like this.
On Mon, Dec 7, 2020 at 3:48 PM Peter C++ via Std-Proposals <std-proposals_at_[hidden]> wrote:
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.
Thanks All for the nice discussion.
Le lundi 7 décembre 2020 à 17:46:40 UTC+1, Gašper Ažman <gasper.azman_at_[hidden]> a écrit :
+1 to what Peter said, but unfortunately the vast amounts of legacy code that one has to put unit tests around *before* refactoring it (not to mention get the refactor funded) mean that we have to have semi-clean techniques of doing stuff like this.
On Mon, Dec 7, 2020 at 3:48 PM Peter C++ via Std-Proposals <std-proposals_at_[hidden]> wrote:
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.
-- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2020-12-07 11:51:27