Timeline for How do you unit test private methods?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 27, 2012 at 11:14 | comment | added | kij | The test will break yes, but this is a minor issue from my point of view.Of course i fully agree about your explanation below on the package visibility (with tests classes in seperate folders but with same packages), but sometimes you don't really have the choice. For example if you have a really short mission in an enterprise which doesn't apply "good" methods (test classes not in the same package, etc.), if you don't have time to refactor existing code on which you are working / testing, this is still an good alternative. | |
| Nov 27, 2012 at 10:42 | comment | added | Richard | While reflection will enable you to test private methods, it is not good for detecting uses of them. If you change the name of a private method, this will break your test. | |
| Nov 27, 2012 at 10:20 | history | edited | gnat | CC BY-SA 3.0 |
spelling, formatting, personal stuff cleanup
|
| S Nov 27, 2012 at 10:01 | review | Late answers | |||
| Nov 27, 2012 at 10:20 | |||||
| S Nov 27, 2012 at 10:01 | review | First posts | |||
| Nov 27, 2012 at 12:16 | |||||
| Nov 27, 2012 at 9:45 | history | answered | kij | CC BY-SA 3.0 |