Day in the Life of an ALM Developer: Write New Code for a User Story

Peter usually develops code in a series of small steps. Each step typically takes no longer than an hour, and might take as little as ten minutes. In each step, he writes a new unit test and changes the code that he is developing so that it passes the new test, in addition to the tests he has already written. Sometimes he writes the new test before changing the code, and sometimes he changes the code before writing the test. Sometimes he refactors. That is, he just improves the code without adding new tests. He never changes a test that passes, unless he decides that it did not correctly represent a requirement.

At the end of every small step, he runs all the unit tests that are relevant to this area of the code. He does not consider the step complete until every test passes.

However, he will not check the code into Team Foundation Server until he has finished the entire task.

Peter writes down a rough plan for this sequence of small steps. He knows that the exact details and order of the later ones will probably change as he works. Here is his initial list of steps for this particular task:

1. Create test method stub—that is, just the signature of the method.

2. Satisfy one specific typical case.

3. Test broad range. Make sure that the code responds correctly to a large range of values.

4. Exception on negative. Deal gracefully with incorrect parameters.

5. Code coverage. Make sure that at least 80% of the code is exercised by the unit tests.

Some of his colleagues write this kind of plan in comments in their test code. Others just memorize their plan. Peter finds it useful to write his list of steps in the Description field of the Task work item. If he should have to switch temporarily to a more urgent task, he knows where to find the list when he is able to return to it.

Usually you would create a new test project for each project that is being tested. If a test project already exists, you can just add new test methods and classes.

This procedure uses the Visual Studio Unit Test Framework, but you can also use frameworks from other providers. Test Explorer works equally well with other frameworks, provided you install the appropriate adapter.

First, create the project where you want to add the new class, unless it already exists.

To generate a class

To generate a method

Peter presses CTRL+R, T to run the new test that he created with Julia. After he writes any test, he always runs it to make sure that it fails before he writes the code that makes it pass. This is a practice he learned after he forgot to place assertions in some tests he’d written. Seeing the Fail result gives him confidence that when he makes it pass, the test result correctly indicates that a requirement has been satisfied.

Another useful practice is to set Run Tests after Build. This option runs the tests in the background every time you build the solution, so that you have a continual report of the test status of your code. Peter was at first suspicious that it might make Visual Studio slow to respond, but he finds that this rarely happens.

Peter writes his first attempt at the code of the method that he is developing:

VB

C#

C++

F#

JScript

PowerShell

No code example is currently available or this language may not be supported.

Peter runs the tests again and all the tests pass:

Now that the code performs its main function, Peter looks at the code to find ways of making it perform better, or to make it easier to change in the future. He realizes that he can reduce the number of calculations performed in the loop:

public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate; 
                estimate = (estimate + x / estimate) / 2;
                //was: estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }

He verifies that the tests still pass:

Tip

Every change you make while you are developing the code should be either a refactoring or an extension: Refactoring means that you do not change the tests because you are not adding new functionality. Extension means adding tests and making the code changes that are necessary to pass both existing and new tests. If you are updating existing code to requirements that have changed, you will also delete old tests that no longer represent the current requirements. Avoid changing tests that have already passed. Instead, add new tests. Only write tests that represent a real requirement. Run the tests after every change.

Peter continues his series of extension and refactoring steps, using his list of small steps as a rough guide. He doesn’t always perform a refactoring step after each extension, and he sometimes performs more than one refactoring step in succession. But he always runs the unit tests after each change to the code.

Sometimes he adds a test that requires no change to the code, but that adds to his confidence that his code works correctly. For example, he wants to make sure that the function works over a broad range of inputs. He writes more tests, such as this one:

VB

C#

C++

F#

JScript

PowerShell

No code example is currently available or this language may not be supported.

This test passes the first time it runs:

Just to make sure this result is not a mistake, he temporarily introduces a small error into his test to make it fail. After seeing the failure, he fixes it again.

Tip
Always make a test fail before you make it pass.

Peter now moves on to writing tests for exceptional inputs:

[TestMethod]
        public void RootTestNegativeInput()
        {
            LocalMath math = new LocalMath();
            try
            {
                math.SquareRoot(-10.0);
            }
            catch (ArgumentOutOfRangeException)
            {
                return;
            }
            catch
            {
                Assert.Fail("Wrong exception on negative input");
                return;
            }
            Assert.Fail("No exception on negative input");
        }

This test puts the code into a loop. He has to use the Cancel button in Test Explorer. This terminates the code within 10 seconds.

Peter wants to make sure that an endless loop could not happen on the build server. Although the server imposes a timeout on a complete run, it is a very long timeout, and would cause substantial delay. Therefore, he adds an explicit timeout to this test:

VB

C#

C++

F#

JScript

PowerShell

No code example is currently available or this language may not be supported.

The explicit timeout makes the test fail.

Peter then updates the code to deal with this exceptional case:

VB

C#

C++

F#

JScript

PowerShell

No code example is currently available or this language may not be supported.

The new test passes, but there is a regression. A test that used to pass now fails:

Peter finds and fixes the mistake:

VB

C#

C++

F#

JScript

PowerShell

No code example is currently available or this language may not be supported.

After it is fixed, all the tests pass:

Tip
Make sure every tests passes after every change that you make to the code.

Peter applies the following principles while developing code:

• Develop unit tests along with the code, and run them frequently during development. The unit tests represent the specification of your component.

• Don’t change unit tests, unless the requirements have changed or the tests were wrong. Add new tests gradually as you extend the functionality of the code.

• Aim for at least 75% of your code to be covered by the tests. Look at the code coverage results at intervals, and before you check in source code.

• Check in your unit tests along with the code, so that they will be run by the continuous or regular server builds.

• Where practical, for each piece of functionality, write the unit test first. Do this before you develop the code that satisfies it.

For more information about how to define a continuous integration build process, see Define a Build Process to Support Continuous Integration. After you have set up this build process, you can choose to be notified about the results of team builds.

For more information, see Run, Monitor, and Manage Builds.