Timeline for How to avoid the need to Unit test private methods
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 26, 2018 at 2:30 | comment | added | Ben | @marstato The name "integration test" comes from testing that multiple components work together (i.e. they integrate properly). Unit testing is testing a single component does what it is supposed to do in isolation, which basically means that its public API works as documented/required. Neither of those terms says anything about whether you include tests of internal implementation logic as part of ensuring that the integration works, or that the single unit works. | |
| Jul 26, 2018 at 0:33 | comment | added | StackOverthrow | @marstato Your entire nomenclature of testing types is shifted one layer relative to mine. | |
| Jul 25, 2018 at 21:05 | comment | added | marstato | @TTK we are talking about the same concept here, but I learned the word "integration test"/"system test" for it | |
| Jul 25, 2018 at 20:42 | comment | added | StackOverthrow | @marstato "The goal of unit testing is to pinpoint where a bug is" - That's exactly the misunderstanding that leads to the OP's question. The goal of unit testing is to verify the intended (and preferably documented) behavior of an API. | |
| Jul 25, 2018 at 20:24 | comment | added | Lewis Pringle | @marstato Thank you! Yes. The tests always pass the first time, when you check stuff in (or you wouldn't have checked it in!). They are useful, as you evolve the code, giving you a heads-up when you break something, and if you have GOOD regression tests, then they give you COMFORT / GUIDANCE about where to look for problems (not in the stuff that is stable, and well regression tested). | |
| Jul 25, 2018 at 20:01 | comment | added | Timothy Truckle | @marstato: suggestion: start writing tests first and change your mind about unittests: they don't find bugs, but verify that the code works as the developer intended. | |
| Jul 25, 2018 at 14:42 | comment | added | marstato | I disagree. IMO, this is 100% correct for integration tests. But with unit tests things are different; The goal of unit testing is to pinpoint where a bug is, narrow enough so you can fix it quickly. I find myself often in this situation: i have very few public methods because thats really the core value of my classes (as you said one should do). However, i also avoid writing 400 line methods, neither public nor private. So my few public methods can only achieve their goal with the help of tens of private methods. Thats too much code to "quickly fix it". I have to start the debugger etc.. | |
| Jul 25, 2018 at 14:35 | history | answered | Lewis Pringle | CC BY-SA 4.0 |