We Keep Coding

Is it possible to exclude a Test Project when running 'Run All' in Test Explorer

I have some Specflow(3.9.40)-based UI test using Selenium Webdriver and NUnit(3.13.2) Framework.
I would like these tests to not run when I hit 'Run All' in the Test Explorer.
In my StepDefinition class I have tried adding the Explicit Attribute:
[TestFixture, Explicit("Only run when called explicitly")]
[Binding]
public class LoginStepDefinitions
{ ...
, but for some reason it does not seem to work - The UI Tests still run.
I imagine there may be something I can add to the [BeforeScenario] in my HookInitialization class, but I am stumped:
[BeforeScenario]
public void FirstBeforeScenario()
{
var seleniumDriver = new SeleniumDriver(_scenarioContext);
_scenarioContext.Set(seleniumDriver, "SeleniumDriver");
}
Is there a way for me to tell Visual Studio Test Explorer to ignore the UI Tests or its folder ?

The basic problem is that NUnit's Explicit setting is unique among the frameworks supported by Test Explorer, which knows nothing of this concept of "explicitness."
If Test Explorer calls the NUnit adapter telling it to run all, then NUnit will honor the Explicit setting. However, in some situations, it simply passes a list of all the tests to NUnit. In that case, all tests appear (to NUnit) to have been run explicitly.
Which way Test Explorer calls NUnit is dependent on the version you are running and it's only possible to tell how it calls by debugging or by observing the outcome. To add to the confusion, some versions of the NUnit3 adapter use heuristics to try to guess whether an explicit test was called explicitly. This doesn't solve your problem but should make it easier to understand what is going on.
The best workaround, if you are using TestExplorer, is to avoid Explicit and to set up categories, which control the running of the tests. Fortunately, TestExplorer and NUnit have pretty much the same understanding of categories.

You can filter tests first in Test Explorer, then the "Run All" button is scoped to only those tests in the Test Explorer panel. If you desire to run all tests except those in a certain project, enter this into the test filter search box in the Test Explorer panel:
-project:NameOfTheTestProject
If your test project has space characters in the name:
-project:"Name of the test project"
Note the - character before the word project. This is crucial. This character tells Visual Studio Test Explorer to invert your filter criteria — it is used to exclude tests in a certain project.
If you have these UI tests intermingled with other kinds of tests, obviously filtering out an entire project is not desirable. Consider placing the UI tests in a specific folder and filter on the FullName instead. For example, if your SpecFlow tests exist in a folder called "Specs", then omit those tests using:
-FullName:Specs
Again, include the - character (with no spaces) before the FUllName criteria to exclude tests in that namespace. This works with SpecFlow because the namespaces for C# classes generated from .feature files follow the folder structure of your test project, just like adding a .cs file does.
This technique should work with any unit test provider, not just NUnit.

How can I split same-project unit tests into separate assemblies?

I have a few test projects, one of which has many unit tests, all very related to doing certain calculations. Running all unit tests takes a long time. So, I'm looking for a way to easily split tests into nightly unit tests and all other unit tests. How can I conveniently specify which test fixtures and test methods should be nightly? In other words, is there a way to split tests from within the same project into separate assemblies?
What I've thought of and tried so far:
Just separate the nightly tests into their own project manually and only run that new project on a nightly basis. This would mean moving files around in the project anytime I wanted to make a test fixture run nightly or regularly, i.e. not desirable.
Come up with a build script that separates these tests at compile time into separate projects. Then I'd end up with separate assemblies. This seems too complicated, but maybe it's the only option.
I would love to be able to use a class attribute to specify which tests will run nightly, e.g.:
[TestClass, Nightly]
public class MyTestClass { }
Any ideas?

You can have as many unit test projects for the same solution as you need.
If you want to go with separate project (i.e. your build system only setup to run test from separate project) I'd have new project sharing tests from old one - create new project and add files from old one as "link" (there is small option on "Open" button of add file dialog to do so).
Alternatively you can add attributes to tests (i.e. TestCategoryAttribute) and make your test runner respect those.

How to make an NUnit TestProject use its own config when run?

Is it possible to let Resharper (or NUnit?) know that I want each test to look for an App.config under it's own project, even when running all tests in a solution together?
Background:
I'm using NUnit and the test-runner that ships with Resharper, and I've got several test-projects in the same solution. Some of my tests depend on config-files located under their respective projects.
When I run a test-project by itself, it will use it's internal App.config, and everything works fine. When I try to run all the tests in the solution, or use the shortcut to run all tests in current test session however, no config-file will be selected, and any test depending on a config will fail by default.
For this reason, I typically end up running all tests in the solution once first, then right clicking the nodes in the test-runner for each of the config-dependent projects, and running them separately afterwards.

Solved:
Apparently assemblies containing NUnit-tests can be run in separate processes or domains using command line options.
For the testrunner under Resharper, this setting can be found under Resharper > Options > Unit Testing.
There is an option "Use separate AppDomain for each assempbly with tests". Checking that solved my problem.

Standard way to attach unit tests to a C# project

I've written couple of unit tests in seperate project. While developing, I loaded the dll into NUnit.exe each time to check the results. Given that I am done with writing unit tests, how to organize and attach unit tests to the solution.
I'd tried creating "tools" folder in the solution directory and then placed all NUnit related libraries and in postbuild event of the test project I hooked up the nunit like below and it works.
"$(SolutionDir)tools\nunit\nunit-console.exe" "$(TargetPath)"
But in one of my tests, I refer to a sqlite DB. If I hardcode its location it works fine but I intend to place it in the tests project under "App_Data" folder. So, I tried with below code to get relative path but it is not working. But when I copied the file to "tools" folder it is working fine, I'd guess execution context is from NUnit folder.
Path.Combine(Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location),"App_Data\\test.txt")

If you don't need specifically nunit, you could as well use built-in visual studio support for unit testing... It has been incorporated to the newest Express editions as well and you don't have to struggle with problems like this ;)
Either way, I believe you've misunderstood the basics of unit testing. We never test against an actual database, that's a very bad practice. You should do some research on the topic and see the theory behind mocking stuff like this.

How to better organize several projects in one solution and their respective unit/integration tests?

I am doing an AI project that currently had the following namespace/package structure:
My ideia is to have some Unit/Integration tests for each one of the modules (probably not for all of them. Startup probably won't be tested).
Each one of these "main" packages is in a different physical file. I'd like to know what you think would be better:
Having for each physical file X.dll a X.Tests.dll
Having a Tests physical file that has the whole lot of tests (doesn't seem like a good idea).
Incorporating Breakthrough's tests in Breakthrough.dll, AI.GeneticAlgorithms in AI.GeneticAlgorithms.dll, etc. I kind of like this solution, as then I won't have my Visual Studio solution explorer cluttered with the the whole set of Test projects.
Thanks!

I would have one Test.dll for each .dll.
It's the way I'm used to work, and I think it's a good method. You now where what is tested.
As Liam already pointed out, the implementation and the tests shouldn't be in the same dll. It increases the size of the delivered dll unnecessarily and you have to deliver all the dependencies of the tests (e. g. unit testing framework, mocking etc.)

Personally, I would have one project/assembly for startup, one for tests, and one for everything else.
Build time increases significantly with multiple projects, so the less projects the better. Unless of course you need to be able to deploy the different packages separately.
Tests are generally not included in the project they are testing because it requires the assembly to take a dependency on any testing frameworks you are using.