Timeline for How to avoid the need to Unit test private methods
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 28, 2023 at 17:02 | comment | added | Timothy Truckle |
@MehdiCharife No. public methods are the official contract of the unit (except they are made public by accident by a careless programmer). When they change (accept renaming) then because new behavior needs this change. Implementations of virtual methods of a parent class should be protected (or whatever the languages equivalent is), not public.
|
|
| Sep 28, 2023 at 14:14 | comment | added | Mehdi Charife | But public methods can also change or get removed without changing the behaviour of other methods that call them (either in the same class or outside of it) yet we still test them. A public method might be just an implementation of a virtual one. | |
| Sep 28, 2023 at 13:29 | comment | added | Timothy Truckle | @MehdiCharife: This is a very strange definition of "public". The Point here is that private methods may change (changed name/parameters/return type) ore be removed completely (inlined) without changing the codes behavior. In that case the Tests should not need to be changed. | |
| Sep 28, 2023 at 10:26 | comment | added | Mehdi Charife | "UnitTests test the public observable behavior, not code," But you can think of private methods as being "public' to the public methods within the same class/module. When you test these privates, you're testing their observable behaviour from the point of view of their public counterparts. | |
| Jul 25, 2018 at 19:53 | history | answered | Timothy Truckle | CC BY-SA 4.0 |