The type of runner you require for your unit test project is entirely dependent on what kind of testing framework they are written for.
If they are written for NUnit, you will choose the type of runner NUnit, for MSTest you will choose this runner.
As for the installation, you simply include the output of your test project libraries in the list of builds. Remember that you can use wildcards in this form, so if you had several unit test projects with a specific naming scheme, you can include them all simply by using the following:
**\*Tests.dll
This will include all files with the name * something * Tests.dll in all folders. You can, of course, hard-code your individual case, as an example that might look like the following:
TeamTests\bin\Release\TeamTest.dll
In my experience, the rest of the options can be left as default. Then TeamCity runs all the tests that it finds in the found assemblies, and automatically refuses the assembly with one test failure.
Regarding external software; if you run tests with the MSTest runner, the build server needs the MSTest binaries available for it. The easiest way to achieve this is to install Visual Studio on the build server, but if you don't need additional bloating, you can follow these steps here to install MSTest without Visual Studio.
If you have chosen NUnit as the basis for testing, no external software is required, as NUnit comes with TeamCity.
source share