You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Guido Tagliavini Ponce <t-...@microsoft.com> on 2015/01/27 20:43:53 UTC
About two Store failing tests
Hi devs,
This email is about two of the Store's tests:
* core/Store/TestNRTCachingDirectory.cs - TestNoDir
* core/Store/TestFileSwitchDirectory.cs - TestNoDir
Essentially, both create temporary directories, delete them, and use its information to create more specific directories (NRTCachingDirectory and FileSwitchDirectory). Just after constructing the latter ones, they assert that those directories do not exist which will be false because the constructors create the directories if they do not exist (in the case of NRTCachingDirectory, the directory is created before calling the constructor using the NewFSDirectory method). Another person already pointed out this in a comment in the first one of the tests.
The easy fix for this would be adding deletion instructions after the second round of constructions. But by doing this we could be hiding some other problem under the rug. Two possibilities that come to my mind:
1. They forgot to delete the directories just before the assertions. This seems unlikely to be happening because it would be an obvious bug.
2. The directories' implementations changed over the time but they forgot to change the tests: Maybe, initially, they didn't create the directories if they didn't exist beforehand.
Knowing the goal of the test could help deciding. If they wanted to test if they could delete those type of directories, then option 1 could be the right one. If they wanted to test that they don't create directories if they don't exist, the other option would fit better with it.
Am I missing out some other possibility? What should we do with those tests?
Best regards,
Guido
RE: About two Store failing tests
Posted by Guido Tagliavini Ponce <t-...@microsoft.com>.
Hi,
I found a difference between Java and C# implementations. Specifically, in the method GetCanonicalPath (getCanonicalPath in Java) from the class FSDirectory, Lucene creates a File object but not a file in the FS (the comment in the head of that method is wrong, because constructing a File object does not create it in the FS), while the .Net version was creating it. Fixing that difference, the two mysterious tests pass.
In my most recent PR I changed that.
Guido
-----Original Message-----
From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On Behalf Of Itamar Syn-Hershko
Sent: Tuesday, January 27, 2015 1:29 PM
To: dev@lucenenet.apache.org
Subject: Re: About two Store failing tests
If you mean:
// LUCENENET TODO mysterious failure - FSDirectory recreates the folder by design, not sure why this passes for Java Lucene
That was me. I pinged someone from Java Lucene to get some reasoning but never heard back. Will try again now. Another option is to debug line-by-line and side by side the .NET and the Java code for the same test, and see maybe they are taking different code paths. I'm assuming that'd be the case. Then try understanding why...
--
Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko> Freelance Developer & Consultant Lucene.NET committer and PMC member
On Tue, Jan 27, 2015 at 9:43 PM, Guido Tagliavini Ponce < t-gupon@microsoft.com> wrote:
> Hi devs,
>
> This email is about two of the Store's tests:
>
> * core/Store/TestNRTCachingDirectory.cs - TestNoDir
>
> * core/Store/TestFileSwitchDirectory.cs - TestNoDir
>
> Essentially, both create temporary directories, delete them, and use
> its information to create more specific directories
> (NRTCachingDirectory and FileSwitchDirectory). Just after constructing
> the latter ones, they assert that those directories do not exist which
> will be false because the constructors create the directories if they
> do not exist (in the case of NRTCachingDirectory, the directory is
> created before calling the constructor using the NewFSDirectory
> method). Another person already pointed out this in a comment in the first one of the tests.
>
> The easy fix for this would be adding deletion instructions after the
> second round of constructions. But by doing this we could be hiding
> some other problem under the rug. Two possibilities that come to my mind:
>
> 1. They forgot to delete the directories just before the assertions.
> This seems unlikely to be happening because it would be an obvious bug.
>
> 2. The directories' implementations changed over the time but they
> forgot to change the tests: Maybe, initially, they didn't create the
> directories if they didn't exist beforehand.
>
> Knowing the goal of the test could help deciding. If they wanted to
> test if they could delete those type of directories, then option 1
> could be the right one. If they wanted to test that they don't create
> directories if they don't exist, the other option would fit better with it.
>
> Am I missing out some other possibility? What should we do with those
> tests?
>
> Best regards,
>
> Guido
>
Re: About two Store failing tests
Posted by Itamar Syn-Hershko <it...@code972.com>.
If you mean:
// LUCENENET TODO mysterious failure - FSDirectory recreates the folder by
design, not sure why this passes for Java Lucene
That was me. I pinged someone from Java Lucene to get some reasoning but
never heard back. Will try again now. Another option is to debug
line-by-line and side by side the .NET and the Java code for the same test,
and see maybe they are taking different code paths. I'm assuming that'd be
the case. Then try understanding why...
--
Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Lucene.NET committer and PMC member
On Tue, Jan 27, 2015 at 9:43 PM, Guido Tagliavini Ponce <
t-gupon@microsoft.com> wrote:
> Hi devs,
>
> This email is about two of the Store's tests:
>
> * core/Store/TestNRTCachingDirectory.cs - TestNoDir
>
> * core/Store/TestFileSwitchDirectory.cs - TestNoDir
>
> Essentially, both create temporary directories, delete them, and use its
> information to create more specific directories (NRTCachingDirectory and
> FileSwitchDirectory). Just after constructing the latter ones, they assert
> that those directories do not exist which will be false because the
> constructors create the directories if they do not exist (in the case of
> NRTCachingDirectory, the directory is created before calling the
> constructor using the NewFSDirectory method). Another person already
> pointed out this in a comment in the first one of the tests.
>
> The easy fix for this would be adding deletion instructions after the
> second round of constructions. But by doing this we could be hiding some
> other problem under the rug. Two possibilities that come to my mind:
>
> 1. They forgot to delete the directories just before the assertions.
> This seems unlikely to be happening because it would be an obvious bug.
>
> 2. The directories' implementations changed over the time but they
> forgot to change the tests: Maybe, initially, they didn't create the
> directories if they didn't exist beforehand.
>
> Knowing the goal of the test could help deciding. If they wanted to test
> if they could delete those type of directories, then option 1 could be the
> right one. If they wanted to test that they don't create directories if
> they don't exist, the other option would fit better with it.
>
> Am I missing out some other possibility? What should we do with those
> tests?
>
> Best regards,
>
> Guido
>