Test::Tiny and/or TAP::Tiny?
Perl test output (the so-called "Test Anything Protocol" or "TAP") is simple: "1..N" declaring that N tests are planned, then either comments starting with "#", or lines starting with "ok X" or "not ok X" saying whether or not test number X succeeded. Generating it should be simple. Parsing it should be almost as simple.
However, the code to generate and parse test output is a byzantine nightmare: Test::Simple and its dependencies are at least 1345 SLOC, and the various TAP-parsing modules are at least 3918 SLOC (including an IteratorFactory!).
Both generating and parsing the subset of "TAP" used by most programs can take around 50 SLOC. This seems like a perfect opportunity for a ::Tiny module.
I blog about Perl.
While I agree that this is fertile ground for a ::Tiny module, I'd urge some caution. There are good reasons that these modules are as complicated as they are. The TAP spec seems simple (and it is compared to things like XML or YAML), but it's not a walk in the park. You need to consider skips, todos, bail outs, descriptiosn, etc.
http://testanything.org/wiki/index.php/TAP_at_IETF:_Draft_Standard
You can probably skip some of the more complicated bits like Diagnostics, nested TAP, meta info, etc.
I'd also recommend that you keep TAP producing and TAP parsing separate. So a Test::Tiny for production and a TAP::Tiny for parsing?
Yes, I currently have a separate Test::Tiny (38 sloc), replacing Test::Simple, and TAP::Tiny (51 sloc), parsing its output. Test::Simple doesn't support them, but I doubt adding SKIP, TODO, and bail-outs would bloat either module very much.
Hi
Sounds like, with docs, these modules would be good to release. I look forward to using them.
I hope you add the other features, including nested TAP, since my module Data::Session uses it.
Cheers
Ron
"Nested TAP" seems the kind of thing that adds complexity while benefitting very few users. Most people's tests don't need anything more complicated than Test::Simple::ok() and "prove", which can be done in a handful of lines.
What problem are you trying to solve?
Making simple things simple. What question are you trying to ask?
Kind of late, I now, but have you considered Vincent Pit's Test::Leaner?
http://search.cpan.org/perldoc?Test::Leaner
Thanks for the pointer -- Test::Leaner didn't appear in my CPAN shell search, and it's still a bit fat, but I'll check it out.
I’m wondering about the motivation: do you have a need that Test::More and TAP::Harness cannot serve?
Does "making simple things simple" meet your definition of "need"?
It’s a means to an end, not quite an end in itself.
And simple how?
In the annals of time, the testing tool set for Perl started out looking about as simple as your code, too. There was a reason it got complicated. Now the question is, what happens when you successively encounter the problems and use cases that led the tool set to its complications – will you punt entirely (“use the complicated thing for that”) and leave your code unable to serve those purposes for the sake of simplicity, or will you just rediscover all the reasons they got complicated and eventually end up in a similar place?
Essentially I am asking here because I have grown a healthy respect for simple-looking problem domains. Simplicity is an absolute good, no doubt, but bears a complicated relationship to the different concern domains. It’s easy to have the wrong kind of simplicity.
I’m not saying you don’t. I just wonder how consciously you are approaching this.
I totally fail to see any need for TAP::Tiny. Harnesses are only run by a few programs (ExtUtils::MakeMaker, Module::Build, prove) and practically never by others. I simply do not see any use case for this. None. Also, keep in mind the TAP Namespace Nonproliferation Treaty. I really think this is a bad idea.
Test::Tiny is not a bad idea per se, but you have to realize what you are giving up when using it. Test::Builder is a whole ecosystem, and not using it really limits your testing possibilities. If you need nothing more Test::Simple's capabilities this may work for you, but you may find yourself needing something more in the future. Test::* is a luxury I wouldn't want to miss when testing. Also, Test::Simple has been in core since 5.6.2, so it's not like you should do it to avoid a dependency.
What, exactly, would most users of Test::Builder be giving up? How many people use anything beyond "ok()" or "is()"?
> How many people use anything beyond "ok()" or "is()"?
Many.
They'd give up Test::Exception, Test::Warnings, Test::NoWarnings, Test::Differences, Test::Deep and countless other Test:: modules. I don't have statistics, but I do believe a lot of others use them too. And if they don't, they could probably improve their unit tests value by starting to use them.