Is there a built-in way to determine if a test is running on a dev machine (within Visual Studio) or on a builder (within the MSTest runner)? If there isn't has anyone found a good solution to this?
I'm using data driven tests and I want to be able to filter the data source on local dev machines, using a home brewed UI, but I want the builder to run all the tests.
I've considered #if but that seems hacky. Any better solutions?
You can use any number of local settings on the dev box that won't be present in the official build or test boxes, and read those to determine if you need to switch to dev-box specific behavior. For example, a file, an XML File, a registry key, a preprocessor directive (as you mentioned).
As Robert Harvey suggested, application settings are another way to do it.
When I've had to make unit tests behave differently on the build machine as opposed to dev machines, I've ended up using Environment.MachineName to determine whether the machine's the build server or not. Don't know if that'll be any use to you.
Whatever you do, I'd just make sure it's well documented so that your colleagues know about it.
I'm successfully using Environment variables and conditional compilation. MSBuild can easily translate environment variables into preprocessor symbols which you can use in your code. Your MSBuild file must include this translation like this:
<PropertyGroup Condition="'$(ENVIRONMENT_VARIABLE)' != '' ">
<DefineConstants>$(DefineConstants);ENVIRONMENT_VARIABLE</DefineConstants>
</PropertyGroup>
What this snipped does is checking for the presence of ENVIRONMENT_VARIABLE and then then appends that variable to the existing DefineConstants list that indicates to MSBuild which symbols to define for compilation.
Defining an environment variable only on your build server/ or only on your dev boxes (depending on what's easier) is a very lean and flexible way to achieve simple configuration. If you need more advanced strategies, config files may be the way to go. But be careful with introducing different build combinations, usually they create a lot of overhead and introduce chance to break the build accidentially.
Whenever you can, avoid it.