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?
I have three working environments:
- Dev (my workstation)
- Build/Test (a TFS instance running on my server)
- 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?