> I don't think I've got the energy to debate basic SW development philosophy: > just do a google on "merciless refactoring" or "agile software development" > (or even "extreme programming").
I don't want to debate SW philosophy, because it is just that, philosophy...everyone has his/her own. I could no more convert you than you could me. The joy of open source programming is that you can do it your way, I can do it mine, and someone can munge them. The only issue I want to make sure we cover is that of documenation. With the Test::More approach, we can easily extract the perl code to produce documentation cases. With your appraoch we can easily modify your test script to produce the perl code. Either way is fine, but we need to make sure it gets done. > If you're > uncomfortable with using abstraction, then by all means stick with the > low-level stuff (sorry, that sounds a bit harsh). Abstractions in code are > best introduced by refactoring., not foresight. Nope, didn't sound harsh at all, and I agree with it. Also, I'm not uncomfortable with abstracting it out, only that we are going to have to generate most of the test cases first, then figure out the correct abstraction. More than likely, the abstractions will make a nice cleanup of the test code, but won't help much more than that. Unfortunately, I'm not sure they do make a nice cleanup of the test code. One has to carefully examine the generation script to figure out what the test is doing. I think tests should be clear, consise, and to the point. Using Test::More, no matter which test script you open, you see perl6 code followed by output. Using the code generation approach, you have to open a test script, decipher what the code generator is doing, then remember that as you wade through the tests...seems complicated to me. I'm not exactly sure where the benefit is. Tanton
