My understanding had been that passing a csproj file as the target argument to NCrunch console exe would tell NCrunch to only run tests in that project. I believe I've seen this behavior work as expected too, however very recently I'm seeing it instead target the entire solution.
Is this because the project is in a subfolder of a a solution that has an ncrunchsolution file that includes a custom engine mode definition?
If that parent solution setting overrides the fact that our command line targets a specific project, what do we do to correctly target just the project?
NCrunch itself doesn't contain any logic to automatically find and load a parent solution for a targeted project. When you run the console tool against a .proj file, NCrunch will create a virtual solution internally using default settings and will load the targeted project into memory, along with all other projects that it depends on.
Assuming this is a test project (which for useful purposes it would likely need to be), it will have dependencies on other projects in its area. NCrunch will load those dependencies and include them in the virtual solution, along with all of their dependencies. So probably you'll end up with a very large slice of your solution being loaded and processed.
Processing dependencies is necessary because NCrunch is a pre-build tool that works from your source code, not from compiled artifacts. This means it needs to load and build every dependency itself.
Remco wrote:NCrunch itself doesn't contain any logic to automatically find and load a parent solution for a targeted project. When you run the console tool against a .proj file, NCrunch will create a virtual solution internally using default settings and will load the targeted project into memory, along with all other projects that it depends on.
Assuming this is a test project (which for useful purposes it would likely need to be), it will have dependencies on other projects in its area. NCrunch will load those dependencies and include them in the virtual solution, along with all of their dependencies. So probably you'll end up with a very large slice of your solution being loaded and processed.
Processing dependencies is necessary because NCrunch is a pre-build tool that works from your source code, not from compiled artifacts. This means it needs to load and build every dependency itself.
OK, got it, that makes sense, and I see now a surprising dependency on other test projects from the one I targeted.
What is the easiest way to have the command line target just one project itself and not its dependent brethren? We're trying to set up a build server to run separate jobs for different test projects, even if they have some mudball relations between them.
Grendil wrote:
What is the easiest way to have the command line target just one project itself and not its dependent brethren? We're trying to set up a build server to run separate jobs for different test projects, even if they have some mudball relations between them.
In terms of build execution, this can only be achieved by restructuring your solution so that there are no build dependencies between your projects. You could do this by replacing ProjectReferences with AssemblyReferences. In this way, NCrunch will treat the referenced projects as being simple binaries rather than projects that need to be compiled and processed. I can suggest no way of doing this that won't involve gutting your projects and making them difficult to work on outside the build system.
In terms of test execution, this would be done using the TestsToExecuteAutomatically filter, either as an engine mode or injected into the tool through the command line. The filter has a condition that can be used to run tests only within a specific namespace. Or alternatively, you could apply a category to the tests at assembly level using NCrunch.Framework.CategoryAttribute inside AssemblyInfo.cs, then use the category condition on the filter.
Grendil wrote:
What is the easiest way to have the command line target just one project itself and not its dependent brethren? We're trying to set up a build server to run separate jobs for different test projects, even if they have some mudball relations between them.
In terms of build execution, this can only be achieved by restructuring your solution so that there are no build dependencies between your projects. You could do this by replacing ProjectReferences with AssemblyReferences. In this way, NCrunch will treat the referenced projects as being simple binaries rather than projects that need to be compiled and processed. I can suggest no way of doing this that won't involve gutting your projects and making them difficult to work on outside the build system.
In terms of test execution, this would be done using the TestsToExecuteAutomatically filter, either as an engine mode or injected into the tool through the command line. The filter has a condition that can be used to run tests only within a specific namespace. Or alternatively, you could apply a category to the tests at assembly level using NCrunch.Framework.CategoryAttribute inside AssemblyInfo.cs, then use the category condition on the filter.
I've got it now, thanks for clearing me up. I'm using TestsToExecuteAutomatically in the command line with IsInProjectWithName to make sure I've got just the test project I want for that build job. Looks like it's working great thanks.