Piers Cawley ([EMAIL PROTECTED]) wrote: > Adam Spiers <[EMAIL PROTECTED]> writes: > > > Is lib/Test/Unit/tests/TestAssertionCodeRef.pm dead? It doesn't > > currently seem to be used. We also seem to be missing tests for > > Assertion::Regexp and Assertion::CodeRef; I'll add those to > > tests/AssertTest.pm along with new tests for the finished ok() > > wrapper. > > I think I wrote it to help with the development and didn't get 'round > to adding it to AllTests.
Ah. Are you going to resurrect it? I didn't understand test_case_to_string at all, nor the $self->assert(qr/bar/, 'foo'); bit :-) > BTW, I've been thinking about the naming and placing of test packages. > > 1. By placing the tests in the ./lib tree they get installed along > with the rest of the testsuite. I'm not sure that this is a good > thing. You're right, it's not. > 2. I've taken to naming my test classes using the same 'lower case > with underscores' approach as that used for method names etc. This > may not be a desperately good naming strategy, but it does help to > distinguish tests from operational code. Sounds reasonable. > 3. On preface (the refactoring engine), I've taken to placing tests in > a tlib directory. This has the advantage of not having tests > installed and lets you use shorter names for your test libraries: > > test::assertion_coderefs instead of > Test::Unit::tests::TestAssertionCodeRef > > If we were to write a 'tlib.pm' modelled on blib.pm we could make > working with a test libs directory reasonably trivial for > developers. A nice idea, but surely this wheel has already been invented in some way? Why not just do something idiotically simple like sticking the test libraries in the `t' directory, and then put use lib 't'; in your t/*.t? (Or better, hack Makefile.PL, or god forbid, ExtUtils::Makemaker, so that a `make test' includes -It as an option when running the tests.) _______________________________________________ Perlunit-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/perlunit-devel
