On Wed Jun 06 00:45:25 2007, ptc wrote: > On Mon Feb 20 14:35:58 2006, jhoblitt wrote: > > > [jhoblitt <!-- x --> at hawaii.edu - Wed Dec 14 01:56:56 2005]: > > > > > > - The framework itself needs tests!!! > > > > > > Parrot::Configure::Data should be low hanging fruit > > > > This has been mustly done since Decemeber with the expection of > > Parrot::Configure::Step. Any help that can be offered would be > > appreciated there. ;) > > kid51, > > you've been working hard on this area, are you able to comment on the > current status of the Configure tests? We might be able to close this > ticket :-)
Assuming we would say completeness was one of our primary objectives, I would have to say: No. But you can form your own opinion by consulting the coverage chart here: http://thenceforward.net/parrot/coverage/configure-build/coverage.html This shows the results of running the configuration tests (generally, t/configure/), then running Configure.pl, then running the postconfiguration (t/postconfigure/) and build tools tests (t/tools/pmc2cutils, t/tools/ops2pmutils, t/tools/ops2cutils). In other words: perl Configure.pl --test Three comments: 1. Parrot::Configure and Parrot::Configure::Step both still have uncovered subroutines. I wouldn't describe them as "low-hanging fruit," because if they were easy to write tests for, I would have done it already. But they should be tackled soon. 2. Large parts of the config/*/* hierarchy are OS-specific. So running tests and coverage on any one OS will not boost coverage across the board. Nonetheless, there are large parts of that hierarchy that are *not* OS-specific. I think the main reason to write more tests for them is that by doing so we increase the number of people who understand WTF is going on in the configuration process. And if at some point we have to come up with non-Perl 5 ways of configuring Parrot, we need to have more people who understand the objectives of the configuration, and not just the language implementing that configuration. 3. The build tools test, mostly in passing, substantial parts of the lib/Parrot/Pmc2c/ hierarchy other than Parrot::Pmc2c::Pmc2cMain (f.k.a. Parrot::Pmc2c::Utils). It would be good to have more unit tests for Parrot::Pmc2c::Library, ::Null, ::Ref, ::SharedRef, ::StandardConst, ::StmRef and ::UtilFunctions. But though those are Perl 5 packages, their focus is very much on C compilation, an area in which others will have to take the lead. (Perhaps this would be a good spot to plug my talk at YAPC::NA::2007, June 28, 9:00 am: Component-Focused Testing: The Case of the Parrot Configuration and Build Tools: http:// conferences.mongueurs.net/yn2007/talk/541. Anyone hoping to work in this area should be able to pick up something there, and I would love to have that opportunity to meet with other current and potential Parrot testers.) kid51
