Adam Spiers <[EMAIL PROTECTED]> writes:
> 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 :-)
Well, it's gonna fail isn't it. I'll take a look at the code when I
get some time. Must write rigged demo for the refactoring engine first
or I'm going to look very silly at the London.pm tech meet...
>> 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.)
Well, it's sort of dependent on where you run the script from.
Actually I'm more inclined to stick the *modules* in t/tlib (I'll
explain why it has to be tlib in a minute) and then do
use lib 't/tlib', 'tlib';
So that you can run the tests from either the project root or from
inside the t directory. It has to be tlib instead of lib to avoid
using the files in lib/* rather than blib/*.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/perlunit-devel
