Ovid wrote:
> For example, with your code (as I understand it):
>
> test {
> my $manager = Feed::Manager->new($some_uri);
> foreach my $resource ($manager->resources) {
> ok my $result = $manager->get($resource), "$resource should
> work";
> }
> }
>
> Imagine that the Feed::Manager connects to an outside resource I don't
> have control over and one day they add a new resource. I now have a
> new test and need to know that something has changed. I don't see how
> your code solves that. One can argue that this is a stupid way to
> test, but I argue that I don't want to tell people how to test.
> However, this seems so completely orthogonal to your point of view
> that it's clear I'm missing something that you've already understood
> :(
The point Mr. Wilhelm has brought up sounds very similar to something
I have been trying (and failing so far) to achieve lately. If it were
done for p6 that'd be great but I think its possible for p5 as well.
The goal is simple: be able to easily alter the plan at any time.
Some nice things become possible if this goal is met.
1. In an xUnit style testing setup, the methods can be decorated with
their plan contribution. The plan can then be built and set before
the TestRunner kicks off the run.
This can be done right now and is done by modules like Test::Class.
The problem comes when any method declares no_plan. When that
happens then the whole plan is shot and has to be set to no_plan.
Thus a major gripe of mine with Test::Class. To me, having a plan
set to no_plan is a sorry exit strategy when the current, very
limited, way of planning fails.
If the plan was easy to alter and the method that declared no_plan
up front can determine its plan contribution at runtime then the
plan can be recalculated and set to a real value.
2. The above loop example would work just fine. The code would just
alter its plan contribution as soon as it could.
To make this happen in p5-land Test::Builder has to support true
"plan at end". It would be nice if Test::Builder defaulted to sending
the plan at the end cause then it would allow this plan altering idea
to work if someone sent the plan out at the beginning of the TAP.
Or allow the second TAP plan, if one is sent, to override the first
one - I don't know. It would also be nice if it had some sort of
plan accounting infrastructure to make it as easy as possible to
keep track of the plan and sub-plans and their histories. This way
the test could just give a new count or a delta and the plan could
recompute itself.
Right now the plan is effectively a one-shot. You either know it up
front or you don't. And if you don't, you lose virtually all the
benefits of planning. Why not allow the plan to reflect what the test
expects at any given time?
The module I've been working on this with is Test::Able.
Its here: http://github.com/jdv/test-able/tree/master
Thanks,
jdv
