Piers Cawley ([EMAIL PROTECTED]) wrote:
> And, dammit, the framework is really useful now and creeping towards
> maturity. I'm thinking of picking the current trunk (with a working
> 'ok') and tagging it 1_0_RELEASE_CANDIDATE freezing the features,
> hammering on it to make it work with 5.7.2, writing a quick tutorial
> pointing people at Test::Unit::TestCase and getting it up to CPAN as
> 1.0 as soon as we're happy with it. The Roadmap for this, as I see it
> is:
>
> 1. Rename Test::Unit to Test::Unit::Procedural
> 2. Rename Test::Unit::HarnessUnit and Test::Unit::UnitHarness
> Not sure what to yet, but I want to get these big API changes out
> of the way before we bump the version number.
> 3. Working ok
> 4. Working build on 5.7.2
5. Change suite-building API so that MySuite really ISA TestSuite,
and gets instantiated via new() rather than the current suite()
nonsense. This is a *big* API change, but I'm utterly convinced
we need to do it. I think it should be possible to keep
backwards compatibility, however.
6. If a testcase fails compilation, you currently get `Suite class
MyTests::Foo not found', rather than `Failed to load ...'; this
needs fixing.
7. Stop `make test' failing when DEBUG is enabled?
8. Move test libraries out of lib/Test/Unit/tests.
9. Deal with broken base.pm in older Perls (or we could always be
nasty and stop supporting < 5.6, best to avoid if we can though).
None of these are big jobs, but I think they should all be done before
1.0 if we want the framework to gain respect and widespread usage;
after all, many people will check out PerlUnit for the first time when
they hear 1.0 being announced, and first impressions count for a lot.
> Nice to have
>
> 1. Test::Unit::Loader working with whole directories.
> 2. <YOUR SUGGESTIONS HERE>
2. Refactoring of runner classes to allow storing state in the
runner. This paves the way for choosing which tests to skip in a
given run, which brings me on to ...
3. Test filtering. I like your Attribute::Handlers idea a lot, and
have a very real need for decent filtering right now.
3. Rethink how the tests are split up between the t/*.t. Currently
we have t/all_tests.t, which is clearly a misnomer, and we have
some tests for the assertion code being run from that rather than
from t/assert.t.
Some of these could be left until after 1.0; however given that I will
certainly be aiming to commit some of them very soon (today, tomorrow
...), it's probably more hassle than it's worth branching off for the
release straight away.
I'll commit all these to doc/TODO now, and then we can twiddle with it
as need be.
Incidentally, we must remember to consult doc/release-checklist before
making a release ...
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/perlunit-devel
