Hi Mark,

Thanks for posting!

It looks to me like your chromedriver.exe is being referenced from the test/project using a relative file path. There's no reason why this can't work with NCrunch, but you need to let NCrunch know about the file so that it can copy it to the workspace used for testing.

Under your project-level NCrunch configuration for your test project, add an extra expression to your 'Additional files to include' to the file path of the chromedriver.exe relative to the project file. NCrunch will then include this file using the same relative file path inside your workspace.

I find it interesting that your test is trying to find this driver inside the _ncrunchreferences. This suggests that the test must be using the file location of one of your referenced assemblies in the expectation that this file is always adjacent to it, which likely won't be the case with NCrunch unless you turn on the 'Copy Referenced Assemblies To Workspace' project-level configuration option for your test project.

Hopefully the above two configuration settings will sort this out. I also recommend having a read of the trouble shooting build issues and workspaces wiki pages as this will help you to better understand NCrunch's workspacing behaviour.

Let me know if this does the trick. If not, we'll try something further.


Cheers,

Remco

Hi Steve, thanks for posting!

The first thing I would check very thoroughly here is to make sure that the IEDriverServer.exe file is in the same directory as Selenium is expecting to find it. NCrunch's workspacing can create an obscure situation where the bin\debug directory of your test project is not necessarily the same bin\debug directory of the other projects being referenced by your test project.

The exception message suggests that the file is being searched for in the current directory. The test runner will usually set the current directory as equal to the bin\debug directory of the test project. There may be a way you can establish for certain whether the file is in the right place by just writing a simple test inside the same test project:

[Test]
public void CheckIfFileExists()
{
Assert.That(File.Exists("IEDriverServer.exe"));
}

If the logic searching for the file doesn't give you any easy options, it is actually possible to set the PATH environment variable inside the test process to include an extra search location. If the file is always at a known location relative to the test's bin\debug directory, you could drop this on the PATH prior to the driver being instantiated. Another option could be to reference the IEDriverServer.exe in its original solution location by using the data provided by the NCrunch environment class, although I would only suggest this as a last resort as it can impact NCrunch's workspace isolation.

Many of NCrunch's features derive from it's ability to separate projects from their parent solution and shadow them inside workspaces. The idea behind this is that while it is in the workspace, the project relies only on files that exist within the workspace. This is to prevent the concurrently running tests from interfering with each other or other activities on your machine (i.e. if you were to test your application manually, it could run safely side-by-side with tests that NCrunch are running). There are also many performance advantages, as NCrunch is able to build projects while they are being used for test execution.

Because the unit test checking for IEDriverServer.exe has passed, I have a feeling that the error message given to you by the selenium driver may be a misleading one. The file clearly exists in the current directory. It may be that the driver is looking for the file in the same directory as the DLL performing the searching, in which case it may be possible to get this working by setting the 'Copy referenced assemblies to workspace' setting to 'TRUE' for all the projects in your solution. Although, to be honest, your workaround by using the PATH is probably a better approach. The 'Copy referenced assemblies to workspace' setting disables many of NCrunch's build shortcuts and will greatly slow response times during testing.