[svn:parrot] r39514 - in trunk: . t/pmc
will at coleda.com
Fri Jun 12 13:18:28 UTC 2009
On Fri, Jun 12, 2009 at 8:32 AM, Andrew Whitworth<wknight8111 at gmail.com> wrote:
> 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.
Changing a todo list to a black list is fine if we declare no tests
are needed, but if we shouldn't be creating copies of this by hand,
then it should be an error to do so, and we should test that error. We
had a similar "no test" laissez-faire attitude for some of the "please
never use these opcodes directly" opcodes, and if you used them
directly, they'd segfault.
If we can't make the instantiation an error for support reasons, then
we should make sure that the current expected behavior works. (at
least be able to instantiate the PMC.)
The fact that the PMC could disappear doesn't mean we shouldn't have a
test while it's here. The test suite should reflect the current design
(such as it is), even if we think that design might change in the
future or if we disagree with the current design.
> --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
>> 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.
Will "Coke" Coleda
More information about the parrot-commits