jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Bug in the TCK Tests for Same-Name Siblings
Date Wed, 14 Sep 2005 07:27:16 GMT
Hi Doug,

thanks for reporting this issue.

McComsey, Doug wrote:
> There is a bug in the Same-Name Siblings tests that makes the first test
> looked like it worked when it actually failed and makes the rest fail
> with misleading messages.
> The TCK tests for same-name siblings derive from these classes:
>     AbstractWorkspaceSameNameSibsTest
>     AbstractWorkspaceCopyBetweenTest
> The tearDown method of the AbstractWorkspaceCopyBetweenTest class is
> supposed to delete the contents of the testroot of the second workspace
> when the tests completes. If setUp completes and the test actually
> starts then it does so. If setUp fails then tearDown does not get
> called.
> Because my implementation does not support same-name, I expect to fail
> the tests. Instead I get this behavior.
> 1. The first test attempts to do the setUp.
> 2. It fails in AbstractWorkspaceSameNameSibsTest.setUp on this
> instruction:
>    if (!isSameNameSibs) {
>        throw new NotExecutableException("Property
> 'sameNameSibsTrueNodeType' does not define a nodetype where sameNameSibs
> are allowed: '" + sameNameSibsTrueNodeType.getName() + "'");
>    }

If a test case throws a NotExecutableException in either setUp() or the 
test method itself the test case is not regarded as failed, instead it 
is regarded 'not executable'. See also my last email.

> 3. The tearDown never executes.
> 4. The test ends successfully with no message !!!!!!!!!!!!!

This is intended, because the test did not actually fail.

> 5. The next test gets an ItemExistsException because of the nodes left
> by the previous test.

I'll fix this asap.

> I have commented out these tests as a workaround but I thought you would
> like to know about the problem.

Your help is appreciated, thanks.


View raw message