Timeline for How do I go about unit testing a private method that gets called in a loop like this one?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 1, 2017 at 12:40 | comment | added | Berin Loritsch |
@UnitTestingN00b, You have to have a reason to change an interface that is centered around the consumer of that interface. I still consider internal methods to be private (assembly/package private), particularly since unit test code is in a completely different assembly and can't access it. Turning a private method public really has to have a good reason for it. Perhaps if your JSON parser only provided a parameter to read a file you could make a great argument for just passing in a stream. But it should solve a problem that users of your class need to solve.
|
|
| Oct 31, 2017 at 22:58 | comment | added | UnitTestingN00b | @BerinLoritsch Sorry for bothering you again. I have always known that I shouldn't test private methods. My question is when do you decide to turn private methods into public (or internal for c#, or move into a supporting class). Sorry for not wording my question correctly. | |
| Oct 30, 2017 at 12:44 | comment | added | Berin Loritsch | @UnitTestingN00b, At some point you'll be creating support classes as well. Most JSON parsers split the work to other classes. At that point, you can test each part individually. But I still stand by my statement. Private methods are implementation details that need to be free to change. | |
| Oct 27, 2017 at 20:18 | comment | added | UnitTestingN00b |
I understand that I shouldn't be testing private methods. My question really is when should I break down a method into multiple testable methods. Imagine a JSON parser that has only one public method called JSON.Parse(). It would be unwise to do all tests through that interface. Is it worth it to make MethodToUnitTest in my sample code directly testable?
|
|
| Oct 25, 2017 at 22:37 | comment | added | Berin Loritsch | @RobertHarvey, I go from the bottom up as well, but I treat each class as if it has its own contract and reason to live. I can get near 100% coverage as well. When classes work together I then test that one class is using the other according to the contracts--i.e. mocking. Typically I start with no private methods, but create them when it makes the code more readable. | |
| Oct 25, 2017 at 20:21 | comment | added | Stop harming Monica | @RobertHarvey Besides language-specific solutions you can always move the method to another class and compose it privately in the original one. That is proposed in the question itself. | |
| Oct 25, 2017 at 16:46 | comment | added | Emerson Cardoso | +1. Also, suggestion to read: blog.cleancoder.com/uncle-bob/2017/03/03/… | |
| Oct 25, 2017 at 15:01 | comment | added | Robert Harvey | I've heard this viewpoint a lot, and I understand why it's promoted, but I still want to have my cake and eat it too. I'm a bottom-up coder in those cases where unit testing has the most value; how can I build up my logic in small methods, unit testing each one, without polluting the API by making those methods public? | |
| Oct 25, 2017 at 12:54 | history | answered | Berin Loritsch | CC BY-SA 3.0 |