3 ms·
> It could be a direct exposure, for example by adding public methods to a class that allow tests to access otherwise private fields in languages like Java or C
by warmwaffles 13y ago
> It could be a direct exposure, for example by adding public methods to a class that allow tests to access otherwise private fields in languages like Java or C++
I hardly test private methods for this very reason. The methods are private and are meant to be helpers. You can poke at it through the method that implements it but I tend to stay away from testing private methods.
- mbell 13y agoI use groovy for writing tests. Much better language for writing tests in general in my opinion but also has the benefit of ignoring 'private' so you can directly test your private methods in isolation without messing around with reflection. To head off the 'only test your public method camp': I often have bits of math or 'tricky stuff' in a private method, the public usages of that method may limit the input to the private method in some manor or map it in a way that offsets edge cases, i.e. an edge case for the public method may not exorcise the edge case in the private method. I'd much rather just test the full input range and edge cases of the private method directly than leave it up to the next person who comes along. The next person may need to tweak the application logic in the public method and then also figure out how to map the application logic inputs to ensure the edge cases of the private method are tested, seems less than efficient and also prone to being missed. It seems silly and fragile to expect that person to figure out the edge cases for the public method, all the edge cases for private methods and the map of public method input to edge case in private method(s).