Re: [egit-dev] Is org.eclipse.egit.core--All-Tests broken in 'master'?

[Mykola Nikishov <mn@xxxxxxxxx>]

Alex Blewitt <alex.blewitt@xxxxxxxxx> writes:

>> As I can see org.eclipse.egit.core--All-Tests is broken in
>> 'master' for some time. Here are steps to reproduce:
>
> So it looks like it's sensitive to the location in which it's
> run. That doesn't sound like a good idea.

Yes, it's sensitive. But, for example, it's a RepositoryFinder's nature,
just look its javadoc:

--8<---------------cut here---------------start------------->8---
 * The search algorithm is exhaustive, it will find all matching repositories.
 * For the project itself as well as for each linked container within the
 * project it scans down the local filesystem trees to locate any Git
 * repositories which may be found there. It also scans up the local filesystem
 * tree to locate any Git repository which may be outside of Eclipse's
 * workspace-view of the world, but which contains the project or a linked
 * resource within the project. In short, if there is a Git repository
 * associated, it finds it.
--8<---------------cut here---------------end--------------->8---

So any unit test that utilizes RepositoryFinder's functionality, like
T0003_AdaptableFileTreeIteratorTest in my case, would be sensitive to
the location too.

> Why don't we create a temporary directory in java.io.tmpdir and then
> run any tests from there, rather than the current directory in which
> we happen to be executing?

It wouldn't help in some cases. For example, I have a git repository in
$HOME/.git and my temporary directory is $HOME/tmp/. BTW, changing
things in a parent directories IMHO considered as a bad practice ;-)

> I don't see that we'll have control of where the user runs the tests,
> even though we might be able to control it for the .launch.

And we wouldn't have that control in any case. We could try to use some
virtual file system to isolate tests from the underlying filesystem or
use some sort of mocks/stubs for filesystem/RepositoryFinder/etc. I'm
out of ideas right now.

The single solution, as I see it right now, is to have properly
configured unit tests with right preconditions asserted. If test breaks
the reason of breakage should be clearly visible, not a cryptic
NPE. It's exactly what proposed patches do.

-- 
MAN-UANIC