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.

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.

1. String eval is the underlying basis of what the Test::* modules do.
2. 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.
3. 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 ....
   [download]

   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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

String eval is the underlying basis of what the Test::* modules do.

You're going to have to show some code to prove that.

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.

Even if I thought you had looked at "most Test::* test suites", the existence of bad code does not prove that it's impossible to write good code. Remember, I extracted Test::Builder so that people could write their own Test::* modules in part to reduce duplication in their test suites. I've also argued for years that refactoring tests is just as important as refactoring production code.

How many novices have responded in this thread?

Your original post talked about people who were learning through doing and implied strongly that you think a contrarian position is important for people who haven't been knocked around enough to see the nuance in things.

If that's not novices, then perhaps you could rephrase things to be more clear. (Several other people in this thread have asked "What does this have to do with the Test::* modules?")

Or perhaps you feel that no debate on this subject is called for?

I suspect that other people object to what you write not because you're wrong but because you can be so unpleasant about it.