You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Simon Svensson <si...@devhost.se> on 2012/07/29 10:56:02 UTC
Why the use of Utils.Paths in TestBackwardsCompability?
I'm looking into running the tests in MonoDevelop (Mono 2.10.9) on a
Mac, debugging one failure at a time. The TestBackwardsCompability tests
fails when unzipping because the paths for the source zip files are
incorrectly calculated. It originates in Paths.AssemblyDirectory, where
it returns a rooted path on Windows ("C:\Users\sisve\..."), but a
relative path on Mac ("Users/sisve/...").
We could use the existing Path.Combine, and choose to copy to
input.xxx.zip files to the output directory. This would remove the need
for the Paths class completely [if I understand it correctly]. (It's
also used from LuceneTestCase to initialize a variable no-one uses.)
Old: System.String dirName =
Paths.CombinePath(Paths.ProjectRootDirectory, "test/core/index/index." +
oldNames[i]);
New: System.String dirName = Path.Combine("Index", "index." + oldNames[i]);
But this makes me wondering, why was the Paths class introduced at all?
// Simon
Re: Why the use of Utils.Paths in TestBackwardsCompability?
Posted by Michael Herndon <mh...@wickedsoftware.net>.
* cause obviously we can not* exactly hard code paths.
On Sun, Jul 29, 2012 at 2:43 PM, Michael Herndon <
mherndon@wickedsoftware.net> wrote:
> to explain further, the shadow copy feature basically copies the test
> assemblies to a different location and executes them from that location.
> However, to my knowledge it does not copy the file resources. The location
> of where a test assembly is located and execute is not guaranteed which
> makes using relative paths fickle, but its required cause obviously we can
> exactly hard code paths.
>
> Shadow copy breaks using relative paths in test code. However if you turn
> shadow copy off, then it kills the workflow of writing tests from within
> visual studio since the test assembly is seen being used by another process
> and blocks VS from rebuilding the test assembly which can be really
> frustrating as you would imagine.
>
> The thing to do is attempt to account for all situations so that people
> can download on whatever box using whatever test tools with as little
> friction as possible. I'm open to suggestions.
>
>
>
> On Sun, Jul 29, 2012 at 2:20 PM, Michael Herndon <
> mherndon@wickedsoftware.net> wrote:
>
>> because of the shadow copy feature in nunit.
>>
>> simply using
>> Path.Combine("Index", "index." + oldNames[i]);
>>
>> won't work when the test assemblies are located in funky places.
>>
>> On Sun, Jul 29, 2012 at 4:56 AM, Simon Svensson <si...@devhost.se> wrote:
>>
>>> I'm looking into running the tests in MonoDevelop (Mono 2.10.9) on a
>>> Mac, debugging one failure at a time. The TestBackwardsCompability tests
>>> fails when unzipping because the paths for the source zip files are
>>> incorrectly calculated. It originates in Paths.AssemblyDirectory, where it
>>> returns a rooted path on Windows ("C:\Users\sisve\..."), but a relative
>>> path on Mac ("Users/sisve/...").
>>>
>>> We could use the existing Path.Combine, and choose to copy to
>>> input.xxx.zip files to the output directory. This would remove the need
>>> for the Paths class completely [if I understand it correctly]. (It's also
>>> used from LuceneTestCase to initialize a variable no-one uses.)
>>>
>>> Old: System.String dirName = Paths.CombinePath(Paths.**ProjectRootDirectory,
>>> "test/core/index/index." + oldNames[i]);
>>> New: System.String dirName = Path.Combine("Index", "index." +
>>> oldNames[i]);
>>>
>>> But this makes me wondering, why was the Paths class introduced at all?
>>>
>>> // Simon
>>>
>>
>>
>
Re: Why the use of Utils.Paths in TestBackwardsCompability?
Posted by Michael Herndon <mh...@wickedsoftware.net>.
to explain further, the shadow copy feature basically copies the test
assemblies to a different location and executes them from that location.
However, to my knowledge it does not copy the file resources. The location
of where a test assembly is located and execute is not guaranteed which
makes using relative paths fickle, but its required cause obviously we can
exactly hard code paths.
Shadow copy breaks using relative paths in test code. However if you turn
shadow copy off, then it kills the workflow of writing tests from within
visual studio since the test assembly is seen being used by another process
and blocks VS from rebuilding the test assembly which can be really
frustrating as you would imagine.
The thing to do is attempt to account for all situations so that people can
download on whatever box using whatever test tools with as little friction
as possible. I'm open to suggestions.
On Sun, Jul 29, 2012 at 2:20 PM, Michael Herndon <
mherndon@wickedsoftware.net> wrote:
> because of the shadow copy feature in nunit.
>
> simply using
> Path.Combine("Index", "index." + oldNames[i]);
>
> won't work when the test assemblies are located in funky places.
>
> On Sun, Jul 29, 2012 at 4:56 AM, Simon Svensson <si...@devhost.se> wrote:
>
>> I'm looking into running the tests in MonoDevelop (Mono 2.10.9) on a Mac,
>> debugging one failure at a time. The TestBackwardsCompability tests fails
>> when unzipping because the paths for the source zip files are incorrectly
>> calculated. It originates in Paths.AssemblyDirectory, where it returns a
>> rooted path on Windows ("C:\Users\sisve\..."), but a relative path on Mac
>> ("Users/sisve/...").
>>
>> We could use the existing Path.Combine, and choose to copy to
>> input.xxx.zip files to the output directory. This would remove the need
>> for the Paths class completely [if I understand it correctly]. (It's also
>> used from LuceneTestCase to initialize a variable no-one uses.)
>>
>> Old: System.String dirName = Paths.CombinePath(Paths.**ProjectRootDirectory,
>> "test/core/index/index." + oldNames[i]);
>> New: System.String dirName = Path.Combine("Index", "index." +
>> oldNames[i]);
>>
>> But this makes me wondering, why was the Paths class introduced at all?
>>
>> // Simon
>>
>
>
Re: Why the use of Utils.Paths in TestBackwardsCompability?
Posted by Michael Herndon <mh...@wickedsoftware.net>.
because of the shadow copy feature in nunit.
simply using
Path.Combine("Index", "index." + oldNames[i]);
won't work when the test assemblies are located in funky places.
On Sun, Jul 29, 2012 at 4:56 AM, Simon Svensson <si...@devhost.se> wrote:
> I'm looking into running the tests in MonoDevelop (Mono 2.10.9) on a Mac,
> debugging one failure at a time. The TestBackwardsCompability tests fails
> when unzipping because the paths for the source zip files are incorrectly
> calculated. It originates in Paths.AssemblyDirectory, where it returns a
> rooted path on Windows ("C:\Users\sisve\..."), but a relative path on Mac
> ("Users/sisve/...").
>
> We could use the existing Path.Combine, and choose to copy to
> input.xxx.zip files to the output directory. This would remove the need
> for the Paths class completely [if I understand it correctly]. (It's also
> used from LuceneTestCase to initialize a variable no-one uses.)
>
> Old: System.String dirName = Paths.CombinePath(Paths.**ProjectRootDirectory,
> "test/core/index/index." + oldNames[i]);
> New: System.String dirName = Path.Combine("Index", "index." + oldNames[i]);
>
> But this makes me wondering, why was the Paths class introduced at all?
>
> // Simon
>