Is there a way to see if a selenium test is being ran via nunit or nunit-console?

Question

So, I have a reasonable amount of Selenium Tests. I want them to run quietly in the background via a batch script, nunit-console, and RemoteWebDriver. I have this setup already. I want to also be able to run the same tests (with me watching, debugging, writing new tests, etc...) with other drivers in visual studios 2013 using nunit. I have this already setup. The problem is I want to be able to run them at the same time.

I'm thinking of putting a check in to see if the calling program is nunit vs nunit-console to determine which driver to use, but I am a little uncertain how I should set this up.

I've considered:

bool isConsole = Process.GetProcessesByName("nunit-console")
                .FirstOrDefault(p => p.MainModule.FileName.StartsWith(@"C:\Program Files (x86)\NUnit 2.6.4\bin")) != default(Process);

if (isConsole)
{ 
   // remote
}
else
{
   // ff,chrome,etc...
}

This however would not allow me to run the suite quietly in the background WHILE running individual tests in visual studios.

Answer 1

I'm not sure if there's any difference when you're running a selenium test, but with a normal nunit test you could do:

if("nunit" == Process.GetCurrentProcess().ProcessName)) {
    ...
}

This gets your the name of the process that's actually executing the tests, rather than just checking if the process is currently running on the machine.

Running from within visual studio, I get a process name of "vstest.executionengine.x86", from the console, I get "nunit-console" and from the gui I get "nunit".

It's possible that depending on the process model that you're running your tests under that you might need to check the parent process, rather than the current process. With Nunit configured to run tests in a separate process the reported process name with the above code is "nunit-agent". For some reason I can't get nunit-console to run in this mode at the moment, so I don't know if it has a different process name that you can use instead.

If you do need to trace up the process call stack to see what the parent process is, there's some excellent answers on how to do it on this question.