|
in reply to Testing methodology, best practices and a pig in a hut.
My colleague Jim Shore just co-wrote a book called The Art of Agile Development. He had the same problem you describe -- how do you teach a novice how to become an expert capable of analyzing different development strategies and practices and choosing the most effective style for one particular team?
His idea for the book was insightful. He wrote the best advice he had, explained the places where it might not work, and said "Try it this way for a few months. When you understand it fully, including where it doesn't work perfectly for you, then change it so it does."
I like his idea, and try to give people the best advice I have. I don't see the value in being contrarian solely for the sake of making the world less clear. |
Re^2: Testing methodology, best practices and a pig in a hut.
by BrowserUk (Patriarch) on Feb 27, 2008 at 08:32 UTC
|
I don't see the value in being contrarian solely for the sake of making the world less clear.
Until that sentence, I had thought that my meditation might have met with your approval. At some level at least.
I am not contrarian for that reason. Indeed, I am not deliberately contrarian for any reason. If I am contrarian, and in this place and environment I certainly seem to be, it's not because I set out to be so.
I try, to the best of my ability, to make informed, logical, concious decisions about things, rather than just adopt the prevailing ethos. I do this in every sphere of life. And when I express my opinions, I try to explain the reasoning and logic that led to my decision. And I only express those opinions in response to direct questions asking for alternative views. Unlike some. And then, I explain my disatisfaction with ABC, and leave the questioner to make their own decision.
On the example that I think concerns you most, the Test::* suite exists and works (for many). But, if I suggested string eval for use in production code, I would be panned. But it is the basis of much of Test::*. If I suggested stealing both STDIN and STDERR from all your production programs, you'd be up in arms. If I suggested you verify the contents of your HTML files, by hard coding comparisons for every line, in sequence, you'd laugh me out of court. Yet for some modules, the test suite is fully a third of the code produced.
There are alternatives. The assert & trace macros in Smart::Comments] for example. Easily enabled. Combine with diff for automation.
As for making the world less clear. So many analogies spring to mind here, but I settle for one: The world would be more clear if there was just one god and everyone had to believe in it. Or none, and nobody was allowed to believe in one. Or many, and everybody had to believe in them all. In some places, at some times, all of those have been legislated. Would you advocate that? To make the world more clear.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
Yet for some modules, the test suite is fully a third of the code produced.
It's a big chunk of Pugs, Rakudo, Parrot, and Perl 5 as well.
Now I'm all for better abstractions and reducing the amount of work to get the right results correctly (I did extract Test::Builder to make this possible for testing, after all), but complaining that a certain unnamed hypothetical test suite seems big to you is just as silly as complaining that you used string eval in a certain unnamed hypothetical production program.
The interesting question to me is "Why?" I agree that a blanket prohibition on one or the other is unhelpful just as I agree that a blanket prohibition on the use of symbolic references or even indirect object notation is unhelpful and likely wrong. That doesn't mean I want to throw a novice head-first into the whole debate over all of subtleties of community idioms and best principles when all he or she wants to do is know why the program doesn't work.
| [reply] |
|
|
but complaining that a certain unnamed hypothetical test suite seems big to you is just as silly as complaining that you used string eval in a certain unnamed hypothetical production program.
My point was that test suites constitute an important part of a production development, even though they may not run on production machines. They consitute a significant part of the development effort. But the prevelant idiom, the use of Test::*, applies different standards to the two sides of projects.
- String eval is the underlying basis of what the Test::* modules do.
- If you encountered the level of c&p coding that exist in most Test::* test suites, in production code, you would (rightly) be up in arms about it.
- If you encountered a (say) config file validation scheme in production code that did:
warn 'Line 1 of config file invalid' if $line[ 0 ] ne '[Section 1]';
warn 'Line 2 of config file invalid' if $line[ 1 ] =~ m[^filename:(\S+
+)] and -e $1;
warn ....
For 400 lines, you'd probably question the methodology used.
That doesn't mean I want to throw a novice head-first into the whole debate...
How many novices have responded in this thread? Where else should such debate take place? Or perhaps you feel that no debate on this subject is called for?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
|
|
|
|
| |
|
|
|
|
