Subj : Re: Not debugging? To : comp.programming,comp.lang.java.programmer,comp.lang.lisp From : dalamb Date : Fri Aug 26 2005 08:34 pm In article <9s0tg1t37q7b0tc591nr78q0m5mgtc3bd9@4ax.com>, George Neuner wrote: >On Thu, 25 Aug 2005 01:24:01 GMT, "Phlip" wrote: > >> >>If you can think of the next _line_ of code to write, you must perforce be >>able to think of a complementing test case that would fail if the line were >>not there. Just make writing the test case part of writing that line. >> > >In principle you're right ... but it's rarely that simple. > >I support testing and assertions wherever possible, including >intra-procedure if there is some meaningful test that can be done on a >partial result - but testing line by line is ridiculous. It may be >extremely difficult or quite impossible to figure out what would >happen if a particular line of code is wrong or missing. It's also >unwieldy because such tests frequently can't be batched but must be >executed in-line due to following code altering the test conditions. You left out the important sentence in Phlip's original where he said "It's not white box testing." From this I deduce he's talking about providing inputs to the unit (method), not adding lines of code to what's being tested. There remains the problem of "figuring out what would happen if a particular line of code is wrong or missing". Once again I plead ignorance of TDD (thankfully Phlip is kind to me when I make mistakes!), but it seems to me that Phlip is talking about the simplest form of "test coverage" which gives us two tests for "if A and B then S" -- one for if true, one for if false. There are more complex forms of coverage such as checking all possible combinations of truth values, and others which look at number of repetitions of loops (somewhere I have an old reference to an article defining a hierarchy of test coverage approaches, which I will try to find if anyone needs it). It seems to me that the line-by-line approach would have to suffer from the same limitations as test coverage: number of test cases grows exponentially as the program gets longer and more complex. I suppose "small methods" helps limit that problem, but isn't it still present? -- "Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5 http://www.cs.queensu.ca/~dalamb/ qucis->cs to reply (it's a long story...) .