Timeline for Does not testing internals entail diligent refactoring and/or rely on developer talent?
Current License: CC BY-SA 3.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 23, 2011 at 5:56 | comment | added | Gishu | @MakeMinePanacea - Ok. I think I see your dilemma : my tests are "specs" ; they are not implementation dependent. e.g. If I want a method that sorts, I write a test that feeds in input data sets and verifies output sets. My test would not be different if I satisfied the spec by implementing BubbleSort or MergeSort. Corner-cases can be tested by passing in different input-sets that would cause the internal code to be executed. If you can post such an example, maybe I can reword it OR I end up learning something new. HTH | |
| Dec 16, 2011 at 21:44 | comment | added | Levin | I see why you shouldn't test non-public items, and I'm not arguing you should [it probably shows thru that I'm skeptical so it's natural you might think I am arguing that]. I'm asking what the implications are to the coder's practice. Your second bullet: "But then the next test should expose this and pull in the real code" -- your tests are designed to test the private implementation's corner cases, right? So formally they only test the interface, but semantically some are targeting privates and you wouldn't write them if your implementation were different? Does that happen? Thanks. | |
| Dec 16, 2011 at 9:39 | history | answered | Gishu | CC BY-SA 3.0 |