Hopfully resolved in 0.04.
Version 0.04 moved all the test support software from the distribution
lib directory to the tlib directory. The installation will no longer go
out to CPAN and install the test support software into the user lib
directory before running the test. Now it just runs the test.
Altough these modules were originally written for test support, they
have other uses. Since they are now in tlib, they will disappear after
the installation. If one wants to use them, they will need to be
individually explicitly installed into lib.
On the issue of "Test::More", the "Test::Tech" module is actually a
very very thin layer on top of the "Test" module.
The "Test" module is actually much more versatile then the comments
of "Test::More" leads one to believe.
Nowithstanding the comments in the "Test::More" module about the single
argument &Test::ok(result) not printing out the actual and expected
values, the two variable input of "Test::ok" i.e
&Test::ok(actual, expected)
will print out the acutal and expected values on failure.
On the issue of testing complex data types, it is true that when you
use &Test::ok(ref_to_actual, ref_to_expected) it will compare the
references and not the data structure. However, comparison of extremely
complex data structures is achieved by stringifying the structures
before passing them to &Test::ok. Usually a simple join is all that is
needed, but there is heavy artilary, Data::Dumper
use Data::Dumper
ok( dump(actual), dump(expected) );
Most debuggers use Data::Dumper to print out variables. Because of its
wide spread use in a extremely high visibility debeggers, the quality
of this module is extremely high. And there is not a separate
subroutine for each and every insignificant change in data structures.
The essence of Test::Tech is that if the actual and expected is a
reference, it passes it thru Data::Dumper before going to &Test::ok so
that you can write
ok( [actual], [expected] );
instead.
On the "Test::More" issue of couting "ok"s, the test script for
File::PM2File was generated by a maker test script from a small test
database. The maker test script counted the "ok"s and used this count
when generating the &Test::plan statement. (Perl is very good for maker
scripts and test maker scripts are easily adapted to generating test
software for other languages i.e C, Fortran, Assembly, APL, Forth ...)
By having a separate test maker script, that generates the actually
test script, all of this activity is removed from the "Test" module.
The "Test" module retains its simplicity and it is immune to feature
creep. This very good for the Test Department since they are not
continually bombarded with extensive "new and improved" "Test"
modules.
Since "Test::Tech" is now in the tlib all of this should be more or
less transparent.
The "Test" module is always going thru updates, so perhaps in the next
version there will be some work with "Data::Dumper" in the code and
better documentation on the versatility of the "Test" module.
For example, there are some very interesting uses of the three
argument "&Test::ok"
