I've found the new TAP::Harness (+ TAP::Parser et. al.) a much welcome improvement in the world of Perl QA. Here's why:
1. The TAP:: & Prove:: framework is well-thought-out and extensible.
It seems many lessons have been learned from Test::Harness & Test::Harness::Straps. TAP::Harness preserves Test::Harness' functionality, and does away with several of its limitations, extensibility being a key one from my POV (there's always going to be something that your company needs or does differently).
As I was writing TAP::Formatter::HTML I found TAP::Parser & TAP::Parser::Aggregator easy to use - the events make sense & the data is well-structured, which makes moulding it into your own format simple. And that you can now easily merge stdout & stderr is *extremely* handy. Finally, if a TAP::* module doesn't do something you need, there's no excuse now: you can just subclass! [update: though some things could be easier to subclass, see RT 36397]
2. The new 'prove' utility makes it *really* easy to run tests.
Why's this so important? Because in my experience, the harder it is to write & run tests the less likely it is for developers to actually write & use them. An unused test suite is a useless. Anything that takes away barriers to entry & use is a Good Thing in my books.
I also like the fact that 'prove' is also designed to be extensible & configurable (eg: ~/.proverc to save you repeating yourself). This makes it feel like a handy unix utility rather than just something that is only used for testing Perl code.
I really like the 'detail' output of Test::TAP::HTMLMatrix, and agree with Kent about how useful such a summary can be, not only for managers but for developers too - it can make tracking down test errors easier because you only need to scan colors rather than lots of text.
But I've got a couple of gripes:
1. it doesn't tell me *why* my tests broke - no debug info, nothing. Just that it was not ok.
2. debug output that goes to stderr still goes to stderr. perhaps this is a T::H::Straps limitation?
3. it's not as customizeable as I'd like. For example, I find it annoying to have to subclass to redefine the css_uri.
4. It's built on Test::Harness::Straps, which is deprecated.
Hence the 3 overall - it's a useful module, but it could be more useful.
This is a really handy module for displaying views of your model as JSON -- if you've done things right in your controller (ie: not coded for a specific view), it just plugs in and works! It also reminds the user of common security problems when using JSON & has sensible defaults, another plus in my books.
I have found it a _bit_ annoying to have to sub-class to configure the JSON encoder (instead of say, a generic config variable like 'json_driver_params' where you could set 'utf8', 'convert_blessed' etc), but that's really a minor gripe. The only other feature I've found it missing is support for embedding responses in 'textarea' tags (for file upload support in iframes), which I've submitted a patch for.
Thanks again... another good point. I was thinking about supporting approximate numeric comparisons, but I hadn't considered the others. You make a good suggestion, but I think I'll reverse it -- Test-Approx-String -- to allow space for a frontend module in the future that supports others... Will rename in the next release.
(old comments for posterity):
Thanks for pointing out that bug - I messed up the name of the module in the Pod. Fixed now.
FYI: the name Test::Approx was inspired by String::Approx. If you've got a better name, I'm all ears...
I've found Geo::Gpx is a handy module for slurping GPX traces generated by my Garmin GPS, munge them some, and output JSON for easy use in my mapping apps in the front-end. It has logical data structures to represent the GPX, and doesn't over-engineer the solution -- arguably Tracks, Waypoints and Routes could be objects to support more functionality, but there's no need for it as it stands, and there's no reason it couldn't be refactored in the future if need be.
A few small gripes: it would be nice to have some sort of search functionality for points built-in (eg: search within a bounding-box, find points at a certain elevation or on a certain date, etc), and it would be nice to support JSON. Hopefully <a href="rt.cpan.org/Ticket/Display.html?id=34...; will sort the latter. The rest you'll have to do yourself, but at least Geo::Gpx takes away the mundane task of processing/creating the XML.