VisualStudioLogoOnce you have your requirements and tasks assigned, your developers can start coding the tasks for the first iteration

This blog follows up two previous posts on how to use TFS for class projects, and how to use TFS for requirements.

If you want more detail on how to start coding your tasks, there’s a nice article in MSDN: how to write code for a user story

Find more Visual Studio Tips and Tricks here.

In this post I will cover

  • Starting to work on a task
  • Creating a Unit Test for your code (it’s actually good to do this before you start coding!)
  • Testing and writing your code
  • Checking your code into Source Control

Don’t forget students can get Visual Studio Professional for free through DreamSpark

Starting to work on a task

As a developer, I live in Visual Studio, and that’s where we start working on the tasks assigned to us. If you open up Visual Studio and go to Team Explorer | My Work, you will see the Available Work Items assigned to you.

Team Explorer assigned work

To start working on a task, just drag it from Available Work Items to In Progress Work.

Team Explorer in progress work

By the way, when you drag an item to In progress, the board for your team project is updated on your team project page. That way anyone on the team who views the board can see that you are working on that task.

Active task on board

Creating a Unit Test for your code

Next I write a unit test for my code. Yes, a unit test! The advantage to creating a unit test for your code before you start coding is it forces you to think about how your method will be called. It’s also going to help me finish my work faster because I’ll have an easy way to test my code right from the get-go.

To add a Unit Test I add a New Unit Test Project.

Create Unit Test Project

When I create the Unit Test project I get a C# file where I can add a test method for the method I am about to start creating. In my project the method is going to convert a pace from minutes/mile to minutes/km. Of course the code does not compile because the method to do the actual conversion doesn’t exist yet.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace UnitTestRunner
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void TestConvertMinPerMiletoMinperKm()
        {
            double minPerMile = 8.0;
            double minPerKm = 0.0;

            minPerKm = ConvertMinPerMiletoMinperKm(minPerMile);

            Assert.AreEqual(5.0, minPerKm);

        }
    }
}

Now I need to add a project to my solution to hold the actual method I am assigned to code. Since this is one of several methods that will be used to do calculations for the app, I’ll put it in a class library.

NOTE: Make sure you choose File | Add New Project  and not File | New project. Because you want to add a second project to your existing Visual Studio solution where the unit test project was created. You don’t want to create a separate solution to hold the class library.

Create Class Library

 

Testing and Writing your code

Okay now I am going to get the Unit test project to generate the method stub for my actual method. If you haven’t discovered the Generate Stub feature yet, I think you will like this! Notice the squiggly red line under the method in the unit test class and the little blue line under the first letter of the method call. This is a hint to me that Visual Studio knows something is wrong with the code and is offering to help me correct it.

generate code squiggle

If I hover over the blue line, an icon appears with a drop down (or use <CTRL>+< . > as a keyboard shortcut). The drop down tells me I can generate a method stub. When I click it, Visual Studio creates a stub for my method. The end result looks like this:

 

          // ...
           minPerKm = ConvertMinPerMiletoMinperKm(minPerMile);

            Assert.AreEqual(5.0, minPerKm);

        }

        private double ConvertMinPerMiletoMinperKm(double minPerMile)
        {
            throw new NotImplementedException();
        }

Now I can quickly test my code any time I want, by just doing a right click in the code and choosing ‘Run all tests’ or CTRL <R><T>. Of course the test will fail if I do it right now, because the only thing my method does is throw an exception.

Test Explorer results

If I just remove the throw exception and add a return statement to my method, the test will pass.

    minPerKm = ConvertMinPerMiletoMinperKm(minPerMile); 

    Assert.AreEqual(5.0, minPerKm); 

} 

private double ConvertMinPerMiletoMinperKm(double minPerMile)
 {
     return 5.0;
 }

Test Explorer Passed

Now I can really start coding and testing. I can add additional test methods to test different scenarios as well, and quickly retest all of them whenever I make a code change.

Checking your code into Source Control

Once I am happy with my code I can check it in.

Since I haven’t done any Source Control Check in or Check out on this project yet, I first need to set up the source control for this project.

Open the Source Control Windows (View | Other Windows | Source Control Explorer)

Source Control Explorer

Select Not Mapped in the Source Control Explorer Window. Select a local folder to map to the folder in the source control.

If you are the very first person to check in code, it’s a good idea to set up a folder structure, so you may want to add a Main folder to your Source Control. From the menu choose File | Source Control | New Folder

NOTE: If New Folder is not enabled, you probably don’t have permissions to create a folder in source control, you will need the Contributor permission for the project. There is an article in MSDN on how to set a permission. Basically go to Team Explorer | Settings | Team Project | Security.

Then in the window displayed, select the Security Tab, then select Users.

Select the user who needs the contributor permission, select Member Of and then choose Join Group, when asked what group to join, type Contributors and Save your changes.

Setting security TFS

Now you can go back to the Source Control Explorer window and create a new folder called main.

New folder source control explorer

 

 

In Team Explorer, choose Pending Changes and choose check in from the Team Explorer Menu, add a comment

Check in

Using Windows Explorer, move your Visual Studio project folder into the Main folder you just created. Remember the local directory which you mapped to Source control? It now contains a Main folder that maps to the Source Control Main folder, so you are moving your Visual Studio project to that folder. That folder on your hard drive is how the source control will detect changes and will place any code that you check out in the future. There is a good MSDN article about how to check in code.

Now open up your project in Visual Studio from the new location. In the Solution Explorer window, right click the solution and choose Add Solution to Source Control. Then right click the solution and choose Check In.

When you choose Check in from the menu, the Pending Changes window appears in Project Explorer so you can review the files that will be included as part of the check in. When you are happy with the list of pending changes, just select Check in in Team Explorer.

Check in Solution

Phew! Okay we accomplished a lot today! We starting working on one of our tasks, created a test project to help us code efficiently and set up the initial source control for our project and checked in the first chunk of code! Give yourself a pat on the back for this step! Personally I have to say I really appreciate the documentation in MSDN as well, it’s been a big help for me in figuring a lot of this out.