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

  • Creating Reactive Applications in .NET

    In modern applications, data is being retrieved in asynchronous, real-time streams, as traditional pull requests where the clients asks for data from the server are becoming a thing of the past.

  • AI for GitHub Collaboration? Maybe Not So Much

    No doubt GitHub Copilot has been a boon for developers, but AI might not be the best tool for collaboration, according to developers weighing in on a recent social media post from the GitHub team.

  • Visual Studio 2022 Getting VS Code 'Command Palette' Equivalent

    As any Visual Studio Code user knows, the editor's command palette is a powerful tool for getting things done quickly, without having to navigate through menus and dialogs. Now, we learn how an equivalent is coming for Microsoft's flagship Visual Studio IDE, invoked by the same familiar Ctrl+Shift+P keyboard shortcut.

  • .NET 9 Preview 3: 'I've Been Waiting 9 Years for This API!'

    Microsoft's third preview of .NET 9 sees a lot of minor tweaks and fixes with no earth-shaking new functionality, but little things can be important to individual developers.

  • Data Anomaly Detection Using a Neural Autoencoder with C#

    Dr. James McCaffrey of Microsoft Research tackles the process of examining a set of source data to find data items that are different in some way from the majority of the source items.

Subscribe on YouTube