lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Herndon <mhern...@wickedsoftware.net>
Subject Re: Why the use of Utils.Paths in TestBackwardsCompability?
Date Sun, 29 Jul 2012 18:43:49 GMT
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 <sisve@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
>>
>
>

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