Missing basepath and privatebinpath arguments in nunit-console

[Patrik Hartlén]

I'm using the basepath and privatebinpath option when running unit tests programmatic on assembly level and the nunit-console application are missing these arguments. See attached patch files (zip) for suggested implementation.

thanks
Patrik

[Charlie Poole (charlie.poole)]

I'm doubtful about this feature, although your patch appears to work cleanly. In general, we place settings that are required to run a set of tests in the NUnit project file, while the command line is used for settings that may change from run to run. The basepath and privatebinpath are in the first category and so are handled in the project file. Have you tried that approach? Here's a simple example for the case of a single assembly:

<NUnitProject>
  <Settings appbase="your/application/base" />
  <Config name="Default" binpath="one/path;another/path">
    <assembly path="your/test/assembly" />
  </Config>
</NUnitProject>

The private binpath is relative to the basepath. All other paths are relative to the location of the .nunit file itself. The basepath defaults to the location of the .nunit file. You can create the file in any text editor, from the NUnit gui or by running the nunit-editor executable.

I'm not rejecting your patch at this time, in case you have reasons why the usual approach won't work for you. However, I don't want to add new options to the command line without good reason.

[Patrik Hartlén (patrik-hartlen)]

Hi,

We have a fairly large system built up by many products reusing assemblies
from core components so when our build system assembles a product the VS
solution file is dynamically built. To avoid creating new nunit project
file for each product we just let the build system run all unit tests
assemblies found in the product solution (subset of all nunit assemblies
in the system).
We use the same strategy for all tools like nunit, fxcop, coverity,
sandcastle etc, eg just dynamically run the tool on each assembly. This
also has the benefit that we can spin off analysis on multiple build
servers to shorten build time in CI.

Still we can of course create new nunit project files on demand if the
patch is rejected.

thanks
Patrik

On Fri, Jul 27, 2012 at 4:58 PM, Charlie Poole <email address hidden> wrote:

> I'm doubtful about this feature, although your patch appears to work
> cleanly. In general, we place settings that are required to run a set of
> tests in the NUnit project file, while the command line is used for
> settings that may change from run to run. The basepath and
> privatebinpath are in the first category and so are handled in the
> project file. Have you tried that approach? Here's a simple example for
> the case of a single assembly:
>
> <NUnitProject>
> <Settings appbase="your/application/base" />
> <Config name="Default" binpath="one/path;another/path">
> <assembly path="your/test/assembly" />
> </Config>
> </NUnitProject>
>
> The private binpath is relative to the basepath. All other paths are
> relative to the location of the .nunit file itself. The basepath
> defaults to the location of the .nunit file. You can create the file in
> any text editor, from the NUnit gui or by running the nunit-editor
> executable.
>
> I'm not rejecting your patch at this time, in case you have reasons why
> the usual approach won't work for you. However, I don't want to add new
> options to the command line without good reason.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1029941
>
> Title:
> Missing basepath and privatebinpath arguments in nunit-console
>
> Status in NUnit V2 Test Framework:
> New
>
> Bug description:
> I'm using the basepath and privatebinpath option when running unit
> tests programmatic on assembly level and the nunit-console application
> are missing these arguments. See attached patch files (zip) for
> suggested implementation.
>
> thanks
> Patrik
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nunitv2/+bug/1029941/+subscriptions
>

[Charlie Poole (charlie.poole)]

OK, that seems like a valid use pattern and the clutter of multiple project files should probably be avoided if possible. It's too late to get this into 2.6.1, so it will have to wait for 2.6.2.

[Charlie Poole (charlie.poole)]

@Simone: This is a new feature (wishlist) and so is postponable if need be.