Re^5: "Practices and Principles" to deathby chromatic (Archbishop)
|on Mar 01, 2008 at 06:57 UTC||Need Help??|
I do not expect a meaningful response to this, because that would require you to actually consider my arguments rather than using spoiling tactics, like exploiting a typo , to dismiss them.
I've long known that American isn't your native language. (The "Uk" in your nickname gives it away.)
This does not respect the level of the invoking code in the callstack. Every test function is exportable and composable, and as such has to set the level at which to print the call trace appropriately.
This prints to the wrong filehandle, so diagnostics might not appear in the output stream.
This doesn't check the test numbers for sanity.
And also consider the less than stellar syntax that it requires.
Besides the camel case, it's not too ugly.
If you are, at the lowest level, going to kick the responsibility of performing a comparison test off to Perl's parser (via string eval), why bother with interspersing all the layers between those comparisons and the Perl parser?
"Hey, if you're going to calculate the Fibonacci function in every Haskell tutorial, why bother writing a program? Why not just look it up in a book?" I'm sure you could trivialize any program to its least interesting part and dismiss it completely for being most uninteresting. I get it. You don't care about any of the other features Test::Builder provides. That's fine. I don't care. You don't have to use them.
Those other features solve plenty of problems for plenty of other people using plenty of other languages and frameworks. You don't have to care about that, either. I can't understand why you do, but that's fine too.
They remote me from the code being tested.
Yes. That's the point. That's exactly why TAP exists, and it's why we can use the Perl test infrastructure to manage Parrot's tests, for example, which are written in Perl 1, Perl 5, Perl 6, Tcl, Lua, Pheme, C, Ruby, PIR, PASM....
Most damning, they prevent me from using the full power of perl to construct my test suite because I am always having to service the needs of the test tool infrastructure by reducing all my tests to simple yes/no answers.
That's half true. It's true in that all good tests ultimately have a yes or no answer. It's false in that the entire point of extracting Test::Builder is so that people could use the full power of Perl to construct test suites without having to service the needs of the test tool infrastructure and without having to worry about the interaction of other parts of the test suite they might also want to use.