lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: About two Store failing tests
Date Tue, 27 Jan 2015 21:28:59 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message