Re: [Perlunit-devel] Towards Version 1.0

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) 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 ...