Boost Team Development with Visual Studio Team System 2008
Working together as a team can be challenging. Here are three ways to use Microsoft Visual Studio Team System 2008 to deliver the best possible software, with as little friction as possible.
Every day you work on developing software to help your company deliver on its mission statement, and you don't do it alone. Maybe your team is a few people; maybe it's a lot of people. Either way, you face obstacles because working together as a team can be challenging; challenges range from ensuring that the code does what it is intended to do and that you have enough test coverage to integrate the work of all team members. Following are three ways you can use Microsoft Visual Studio Team System 2008 to help you and your team deliver the best possible software, with as little friction as possible.
Ensure quality with unit testing and code coverage
One of the issues most developers face is ensuring that they are writing high-quality code -- that is to say, it performs well and meets the expectations defined by the requirements. A technique you may already be using is unit testing. A unit test enables you to automate the verification of a small piece (a unit) of code. Here is a simple example of a unit test:
public void DivideReturnsCorrectValue() {
MathHelper helper = new MathHelper();
int a = 4;
int b = 2;
int expected = 2;
int actual;
actual = helper.Divide(a, b);
Assert.AreEqual(actual, expected);
}
In this unit test, an instance of the MathHelper object is tested to ensure that the Divide method returns the expected result. If anything other than the expected result is returned, the unit test will fail. This is a great way to ensure that the code is working as intended. It may require several tests to completely validate a particular method. For example, the Divide method may look like this:
public int Add(int a, int b) {
if(b == 0)
throw new ArgumentException("b cannot be 0.", "b");
return a/b;
}
In this case, the previous unit test never verifies the exception case; thus, the code is not adequately tested.
With Visual Studio Team System, you can augment unit testing with code coverage, which reports on which code was and was not executed during the test run. Code coverage will report on the percentage of code covered and provide color-coded highlights indicating exactly which lines were and were not executed.
You can enable code coverage using Visual Studio Team System 2008 Test Edition, Development Edition or Team Suite by following these steps:
- From the Test menu, select Edit Test Run Configurations and select the configuration you intend to use for this run -- localtestrun.testrunconfig is the default name of the file.
- Select the Code Coverage page in the resulting dialog box.
- Select the binaries you want to be instrumented and click Apply.
- Click Close to dismiss the run configuration properties window.
- Execute the tests either through Test Manager or Test View.
- From the Test menu, select Windows > Code Coverage Results to view the code coverage results.
Code coverage data will help ensure that you are testing all of your code or, conversely, help you identify code that is not being tested yet. But remember, just because a line of code was tested once, doesn't mean it was tested thoroughly. Spend some time to ensure that you are writing enough unit tests to exercise success and failure conditions as well as boundaries and exception cases.
Set up a testing policy in version control
Using unit tests is a great way to ensure the quality of the code you are writing; however, if all members of the development team aren't writing and running unit tests as part of their development workflow, the code coverage goes down and the value is quickly lost. Typically, a development team will agree that everyone must run unit tests prior to checking code into Visual Studio Team Foundation Server. You can reinforce this with a Check-in Policy.
Check-in policies are simple mechanisms that will prevent a code check-in until certain criteria have been met, such as running and passing all unit tests. Out of the box, Visual Studio Team System 2008 Team Foundation Server ships with a Testing Policy that you can enable. With this policy, you can define one or more test lists that must be run prior to checking in any code.
- From the Team menu, select Team Project Settings > Source Control.
- Select the Check-in Policy tab.
- Click the Add button.
- Select the Testing Policy and click OK.
- In the Testing Policy dialog box, click Browse to select the Metadata file.
- Navigate to the location of the .vsmdi file in your project.
- Select one or more test lists that you want to have run prior to check-in and click OK.
- Click OK to close the Source Control Settings dialog box.
Your project is now set up to require that the specified test list(s) is run immediately prior to check-in and that all tests in the list(s) pass. You can ensure that this is working by changing a line of code in a file and attempting to check it in without running the tests. As soon as you attempt to check in the code, you'll see a Policy Failure dialog box, indicating that the policy requirements have not been satisfied.
Integrate and validate code frequently with build automation
Integrating code in a single team repository, such as Visual Studio Team Foundation Server, is a best practice that all development teams should use. Simply having the code in a single repository is not quite enough, though. To get the real benefit of integrating the code, you need to build the code and verify it. There are a number of options here, including scheduled builds that run nightly and/or weekly, as well as builds that run after every code check-in.
In Visual Studio Team System 2008, you can set up a continuous integration build definition. This build definition will trigger the build process every time there is a code check-in. In addition, you can include a test run as part of the build process, which will verify the build result. This means that you will know almost immediately if any code check-in causes a build break.
Here is how you can set up a continuous integration build:
- From the Build menu, select New Build Definition.
- In the Build Definition properties, name the build something that identifies it, such as Dev CI Build.
- Go to the Project File properties page and click Create to open the MSBuild Project File Creation Wizard.
- Select the solutions to build and click Next.
- Chose the configuration (Release or Debug, etc.) and click Next.
- Select the check box to indicate that this build will include a test run.
- Select one or more test lists that you want to run, or select to automatically detect and run tests (with this option, you can define a wildcard statement indicating what the name of a Test assembly looks like, such as Test*.dll).
- Click Finish to return to the Build Definition properties.
- Go to the Build Defaults page and select a build agent and define the path to the share where the build artifacts will be dropped, such as \\localhost\Drops.
- Go to the Trigger page and select Build each check-in, and then click OK.
You have just created a new build definition that will be triggered each time code is checked in. A test run will be included as part of the build process. You can test this by editing a source file and checking it in. Once the code is checked in, the build request will be queued and the build process will start running.
Visual Studio Team System 2008 is a complete application lifecycle management solution designed to help your team work better together. The suite of products offers even more than this, and the best thing you can do is simply get started -- use the tips in this article to take those first steps.