Developer Product Briefs

Deploy Supporting Files as Part of Your VSTS Unit Tests

It can be complicated to move configuration files in a post-build event with Visual Studio Team System. You can make things easier with one of two options.

Deploy Supporting Files as Part of Your VSTS Unit Tests
If you're using Visual Studio Team System for creating and managing unit tests, you'll find that it does things a little differently.
by Benjamin Day and Richard Hale Shaw

July 24, 2006

App.config isn't the only place to keep configuration values: Some third-party tools, such as NHibernate, have their own configuration files (e.g., hibernate.cfg.xml). So when you write tests for code that uses these tools, these files need to be in the bin directory when you run your VSTS unit tests. Sounds easy, doesn't it? Set up a post-build event that copies any additional files into "bin\Debug" and you're good to go, right?

Not so fast.

If you're using VSTS for creating and managing unit tests, you'll find that it does things a little differently. The reason? With VSTS, you're not just operating by yourself: You're creating materials that can be shared with the rest of your team. Further, each time you run a test fixture ([TestClass]), VSTS creates a new directory containing fresh copies of your unit test binaries. This complicates moving configuration files in a post-build event because you don't know what the name of that directory is going to be. VSTS is smart enough to move your app.config to the right place—but it ignores any other files.

What to do? You have two options: Use the DeploymentItem attribute or modify the test run configuration.

[DeploymentItem] allows you to specify a file that should be copied before your [TestMethod] is run, for example:

[TestMethod()]
[DeploymentItem("MyConfigFile.xml")]
public void FileExistsTest()
{
	FileReader target = new FileReader();

	Assert.IsTrue(target.FileExists(),
		"Could not find config file ({0}).",
		target.GetConfigurationPath());
}

[DeploymentItem] has a major drawback: It's allowed only on methods—not classes. This might be fine if your configuration file is required on only a few test methods, but it quickly becomes impractical if you're using the configuration file with every test in a fixture or every test in a test assembly.

If you need to use your configuration file in lots of tests, a better solution is to modify the test run configuration file. VSTS creates a test run config file whenever you create a VSTS Test Project, stores it in your Solution's Solution Items folder, and names it "localtestrun.testrunconfig" (see Figure 1).

To modify the test run config file, double-click on it, bring up the test run configuration editor, then click on Deployment. Click on the Add File and Add Directory buttons in the resultant dialog to select files and directories to deploy with each test run (instead of just an individual test) (see Figure 2).

About the Authors
Benjamin Day is an independent consultant specializing in the design and development of Web and Windows applications using Microsoft .NET technologies. Ben also provides consulting and training on Visual Studio Team System and Team Foundation Server through The Richard Hale Shaw Group. He is a Microsoft MVP for C#, speaker at VSLive! and other conferences, and the leader of the Beantown.NET INETA User Group in Boston. When not developing software, Ben plays piano with a Boston-based jazz trio and is an enthusiastic restaurant, food, beer, and wine buff. Contact him through www.benday.com.

Richard Hale Shaw is the founder of The Richard Hale Shaw Group, which has consulted and trained software developers since 1993. He's created and chaired numerous technical conferences, including VSLive!. You can reach him at www.RichardHaleShawGroup.com.

About the Author

Benjamin Day is an independent consultant specializing in the design and development of Web and Windows applications using Microsoft .NET technologies. Ben also provides consulting and training on Visual Studio Team System and Team Foundation Server through The Richard Hale Shaw Group. He is a Microsoft MVP for C#, speaker at VSLive! and other conferences, and the leader of the Beantown.NET INETA User Group in Boston. When not developing software, Ben plays piano with a Boston-based jazz trio and is an enthusiastic restaurant, food, beer, and wine buff. Contact him through www.benday.com. Richard Hale Shaw is the founder of The Richard Hale Shaw Group, which has consulted and trained software developers since 1993. He's created and chaired numerous technical conferences, including VSLive!.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube