Timeline for How do you unit test private methods?
Current License: CC BY-SA 3.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 30, 2020 at 2:48 | comment | added | Ric Jafe | Also there is a sound argument that if you feel the need to test a private method then your class most likely is doing more than it should and thus breaking the Single Responsibility Principle. So it could be an oportunity to extract to a new class that method/behaviour. | |
| May 19, 2020 at 8:42 | comment | added | Flater | @hellboy: Stubbing something entails it being public knowledge, which is not what a private method is. As this answer explores, private methods are implementation details whose existence is not relevant to anyone but the owning class - stubs are decided by someone else who doesn't know of the private function and thus wouldn't know it should/needed to be stubbed. | |
| May 18, 2020 at 21:02 | comment | added | Flater | @quant_dev: "If you paint yourself into a corner, you're going to have to walk on the paint" (which is valid, and what I suspect you mean) is not the same as "you have to sometimes walk on paint" (what you ended up implying). If the private method can be meaningfully tested by itself, then it is a unit in and of itself and warrants a class of its own. In your "valid" example, you're dealing with an overloaded class, a lack of single responsibilities and separation of concerns, and coupling that is way too tight. That's the corner you would've painted yourself in for your advice to apply. | |
| Sep 3, 2015 at 2:57 | comment | added | Michael Plautz | @TallGuy though you are correct that this answer does not technically answer the asked question, it does answer the question the OP intended to ask (what he actually wanted vs. what he said he wanted). Math Student: How do I properly divide by 0? Math teacher: You don't. (Of course you can divide by 0 - in engineering mathematics - but proper guidance says you ought not to). | |
| Aug 9, 2015 at 12:04 | comment | added | 王奕然 | if you use tdd,the test method generally test public or protected method | |
| Apr 10, 2015 at 15:15 | comment | added | Adam Lear♦ | @hellboy In what context? What does the private method you want to stub out do? | |
| Apr 10, 2015 at 11:46 | comment | added | hellboy | How can I stub calling private method? | |
| Jan 30, 2014 at 22:40 | comment | added | Adam Lear♦ | @TallGuy Allow me to distill my answer here to its core point. The answer to "how does one unit test private methods?" is "One doesn't." | |
| Jan 30, 2014 at 22:39 | comment | added | TallGuy | This answer DOES NOT answer the question. The question is how should private methods be tested, not whether they should be tested. Whether a private method should be unit tested is an interesting question and worthy of debate, but not here. The appropriate response is add a comment in the question stating that testing private methods may not be a good idea and give a link to a separate question which would go into the matter more deeply. | |
| Nov 27, 2012 at 15:23 | comment | added | jhocking | In retrospect I worded that statement too absolutely; you're right that a general purpose library could be an exception. Although note that we were talking about 'private' methods, not 'public'. If you are writing a library then that probably means there are others using it so you can't be sure a public function isn't being used by someone, whereas you know for sure which private methods are not being used. And regardless I don't think extra methods hanging around are a huge issue, more of a code smell. | |
| Nov 27, 2012 at 9:53 | comment | added | Giorgio | @jhocking: When you define the API of some library module (especially if it is a general-purpose module), you do not consider the public functions that you actually use in your current code, but the public functions that one would expect to find in such a library. So you do not keep adding and removing API functions just because you need / do not need them in your current code. | |
| Jul 17, 2012 at 15:32 | comment | added | quant_dev | @Phil Complex object graphs are also a code smell. | |
| Jul 17, 2012 at 14:47 | comment | added | Phil | @quant_dev: Sometimes a class needs to be refactored into several other classes. Your shared data can be pulled into a separate class too. Say, a "context" class. Then your two new classes can refer to the context class for their shared data. This may seem unreasonable, but if your private methods are complex enough to need individual testing, it's a code smell that indicates your object graph needs to become a little more granular. | |
| Apr 12, 2012 at 19:03 | comment | added | Adam Lear♦ |
@Hugo Sure, you could. I'm not sure I understand the question. So long as your tests cover the required/expected behaviour of Thing() its implementation is irrelevant.
|
|
| Dec 28, 2011 at 11:21 | vote | accept | Vinoth Kumar C M | ||
| Aug 14, 2011 at 11:44 | comment | added | jhocking | Of course delete it. The only possible reason not to delete a function you aren't using is if you think you may need it in the future, and even then you should delete it but note the function in your commit logs, or at least comment it out so that people know it's extra stuff they can ignore. | |
| Aug 14, 2011 at 10:56 | comment | added | Steven A. Lowe | @Hippo: if your class has a private method that is never called, it is dead code and you do not need it. – | |
| Aug 14, 2011 at 10:08 | comment | added | Hugo | @AdamLear: But then couldn't you just stick all the contents and logic of public Thing() into private DoThing(), have Thing() call DoThing() and just unit test the simple Thing()? | |
| Aug 14, 2011 at 9:19 | comment | added | Hippo | @Steve: "delete it"?!!? | |
| Aug 14, 2011 at 8:04 | comment | added | quant_dev | I disagree. Sometimes a private method is just an implementation detail, but it still is complex enough that it warrants testing, to make sure it works right. The public interface may be offering a too high level of abstraction to write a test which directly targets this particular algorithm. It's not always feasible to factor it out into a separate class, for due to the shared data. In this case I'd say it's OK to test a private method. | |
| Aug 14, 2011 at 6:08 | comment | added | Steven A. Lowe | +1 bazillion. And if a private method is never called, don't unit-test it, delete it! | |
| Aug 14, 2011 at 5:40 | history | answered | Adam Lear♦ | CC BY-SA 3.0 |