How to run machine-specific tests during DevOps remote build

Question

What are the generally accepted means of running tests that pass on the dev machine on the build server where they'll consistently fail due to missing dependencies? (In this case, a configuration file that is managed by another completely external application.)

My app is reading an INI file containing various key/value pairs, and I'm storing the path to that file in App Settings. This works fine in my dev environment and in production as well.

But what about when I send all of this to TFS for a build? Those tests are going to fail because neither the INI file nor the Path setting pointing to it exist on the server (nor do I think they should, but I may be mistaken with this).

To quote Jon:

Typically a build machine is meant for build, compile + unit tests. There should be no external dependencies.

Should I include logic to just skip those particular tests if they're not running in dev?

--EDIT--

I have three working environments:

1. Dev (my workstation)
2. Build/Test (a TFS instance running on my server)
3. Production (the application running at the customer site)

The app has a UI for specifying the path to the INI file. This path is stored in App Settings, which in turn is stored in a subfolder under %AppData% (in Windows). The file is created and updated by an external application whose source code is not under my control.

Tests succeed in Dev and Prod, but fail in Build due to the fact that neither the INI file nor the Path setting pointing to it exist in Build.

According to my research, external dependencies (like this INI file and its corresponding setting) should not be introduced in a Build environment. I tend to agree. It seems small now with just this one instance, but I can easily foresee this spiraling out of control as more such scenarios are introduced.

It wouldn't take much of this before Build became choked down with all of these specialized, tightly coupled, brittle and difficult-to-maintain configurations.

How do we get out of this Catch-21?

Answer 1

Its best to design your program so that it is able to run after it's built.

In this case you need a default path in app settings, pretty easy, and a default ini file to be copied to that path.

Include these things in the project and if necessary add post build steps to move them to the right path or what have you.

Alternatively, you might consider these test Integration tests. In which case, don't run them immediately after build. (Skip them by adding categories to your tests, so you have unit and integration) First deploy the program to your test environment with another automated step (Octopus deploy?) and then run them.