Actually, there is no matter if you use NUnit or something else. TeamCity is able to track NUnit tests and report all tests information on-the-fly. For that feature you do not need to change the build.
TeamCity automatically replaces NUnit calls from NAnt with <nunit2> task or MSBuild with <nunit> task from MSBuild Community tasks. For Visual Studio solutions there are UI options to enable unit tests. In anyway if you want to run NUnit tests you may use mentioned tasks in you build scripts or even call an .exe to run the tests.
TeamCity supports NUnit 2.2.10, 2.4.1, 2.4.6, 2.4.7. Actually, there is really a small difference what NUnit test runner to use. There is no strong dependency between NUnit test runner and NUnit.Framework.dll that is linked to the application.
Tests may require to be started under exact NET 1.1 (or .NET 2.0). In case .NET 2.0 there is an option x64 or x86. Under TeamCity it is easy to specify it.
For NAnt you have to specify target framework to .NET 1.1 and that would start your tests under .NET 1.1
If you use command line for your tests it would look like this:
$(teamcity.dotnet.nunitlauncher) v1.1 MSIL NUnit-2.4.7 <list of assemblies>
To select .NET 2.0 x86 or .NET 2.0 x64. For NAnt you will have to define property named 'teamcity.dotnet.nant.nunit2.platform'. Values could be x64,x86,MSIL. For command line runner it would look like:
$(teamcity.dotnet.nunitlauncher) v2.0 x86 NUnit-2.4.7 <list of assemblies>
All mentioned settings are available on Sln2005/Sln2008 runners from TeamCity Web interface.
For MSBuild TeamCity defines task called NUnitTeamCity. It is possible to define any behavior of the tests under TeamCity. Using Platform attribute it is easy to select platform (x64 or x86) to run your tests. NUnitVersion attribute allows to select NUnit test runner version.
And finally, if some test has failed you will be notified at the exact time of that failure. You do not need to wait for all tests to finish.
