[svn:parrot] r39514 - in trunk: . t/pmc

[Andrew Whitworth]

I've been thinking about this issue since yesterday, and I believe now
that the test is in error and should be changed. The PMC in question
is abstract, it's not intended to ever be instantiated or used
directly. The benefit in it comes from using it to inherit from so
other IO-related PMCs have a common base to work with. Plus, in the
next round of cleanups this PMC may disappear entirely if we find that
there isn't enough common base that's worth inheriting like this.

So we already have tests for the things that use this, FileHandle and
StringHandle, etc. It doesn't make any sense for us to put in an empty
worthless test file for every abstract PMC type that we choose to
define in the future. A better solution would be to add a blacklist to
the test so PMC types that can't be sensically tested directly don't
have to be.

--Andrew Whitworth

On Fri, Jun 12, 2009 at 7:48 AM, Will Coleda<will at coleda.com> wrote:
> In my opinion, this is not a good way to silence the test error.
>
> Now, the test passes, but there's no indication that the thing it was
> testing isn't really done, and so there's no incentive to meet the
> actual goal (testing the PMCs), not the literal goal (does a test file
> exist?)
>
> If we have to silence this error (say, for the release), then a better
> solution is to TODO the test for this particular PMC. This at least
> keeps all our "This test isn't passing yet" information consolidated
> in the t/ directory.
>
> There should also be a ticket associated with that TODO marker.
>
> See https://trac.parrot.org/parrot/ticket/493 for a similar case where
> we went down this path.