Hi, I am looking to use NCrunch in a rather unusual way.
At the moment, I have NCrunch setup with distributed processing to manually execute functional GUI tests on VirtualBox VM's. All these VM's are run locally, on my development laptop.
Since I am manipulating all kinds of Windows services during these GUI tests, I sometimes break the environment of the VM.
This gives me problems: all tests that run on this node after breaking the environment automatically fail.

To solve this issue, I would like to be able to setup the VM and tear it down again in my test code.

Ideally, the flow would go as this:
1: In Visual Studio 2015, I right click on an NCrunch test and choose 'Run selected test on server' -> 'Node 1'.
2: The VM of 'Node 1' is booted, NCrunch connects to this node and starts remote test execution (of only this test) after building the solution.
3: After test execution, the VM of 'Node 1' is shut down.

I understand that this might be impossible to do. However, the following flow would still be acceptable:
1: In Visual Studio 2015, I run a test from the VS Test Explorer (using NUnitV3 test adapter)
2: The test itself knows that it needs to boot up the VM 'Node 1'.
3: The VM of 'Node 1' is booted by the test, NCrunch connects to this node and starts remote test execution (of only this test) after building the solution.
4: After test execution, the test result is fed back into the VS Test Explorer.
5: The test shuts down the VM of 'Node 1'.

Now, I think that the 2nd scenario is possible using the Console version of NCrunch.
I've been looking through the documentation of the NCrunch console, however, and I can't seem to really figure it out.
I have the following questions:
- Is it possible to drive NCrunch programmatically to connect to a Node?
- Is it possible to tell an NCrunch node to only run 1 test programmatically? Do I have to create seperate engines for each test?
- How do I route the test results back into the NUnit test adapter?

The answer to some of these questions might be obvious.
I'm not very experienced in working with VM's and the documentation for the console is a little lacking, honestly.

The ideal solution would be that I could tell the host computer, which is running NCrunch in VS2015, to run some scripts (that setup the VM, for example) before building and testing the solution on a remote Node when I tell NCrunch to run the tests.
The problem I have at the moment is chicken and egg: all tests are run in the Node's NCrunch workspace, so I can't use a SetupFixture or anything to setup my VM, since the VM needs to already exist in order to run the test.

Hi, thanks for posting!

Short of an unstable solution requiring considerable micro-management, I don't think it's possible to get the NCrunch infrastructure to behave in the way that you've described. This is because what you are after is effectively a dynamic grid node that is remotely controlled with user code. At the moment, the only places where NCrunch is able to execute user code is in the tests themselves or in the build process.

I would instead urge you to think of this problem in a different way. This isn't really a distributed processing problem - it's more of a compatibility testing problem. The VMs themselves are essentially just an extension of the tests; they don't exist to scale the NCrunch engine, rather they are transient containers to isolate unstable code from the development environment.

The best way to resolve this is to build the infrastructure into the tests themselves. If you have a use case that requires code to be run in a VM, place all this code within the scope of a single fixture. In the setup code for the fixture, initialise the VM and open a network connection to your own software running inside the VM that executes the test code. The results are then reported back over the network connection and the VM can be torn down in the teardown code at the end of the run. It takes a bit of plumbing to get this up and running, but it does work very well. You can then look into scaling this solution horizontally using NCrunch distributed processing, where each grid node has their own set of VMs.

Sorry, there may not be much I can do to help you then. The kind of setup you're looking for would require considerable changes to be made to the NCrunch engine. I'm not personally aware of any project that will enable such a setup out of the box.

You are always most welcome to post feature requests to uservoice. This would make excellent sense as a feature request, and I agree it would be a valuable feature.

However, as developers we do often tend to oversimplify these sorts of problems on first glance. Because NCrunch is a packaged product, such a feature would require a certain level of polish before it could be considered safe to release. There are many edge cases to consider and the feature would need to fit with the existing model so that people could easily make sense of it. I say this only to try to help you understand that nothing is ever as simple as it seems with such a complex product.

I can say at this stage that there won't be any kind of movement on such a feature within the next 3 months.

This is because the product is undergoing major upgrades to handle the next generation of .NET (.NET core).

Beyond this, it depends entirely on how badly the feature is wanted (i.e. votes in uservoice etc) as to whether it is scoped.