Day 1
A Lap Around Team Foundation Server
This module presents an introduction to Microsoft's Team Foundation Server, a platform for integrating and managing all aspects of the software development process. It provides an overview of the Team System Client applications and the Team Foundation Server, discussing how and where each feature fits into the software development cycle and how it pertains to each project role.
This module also presents an introduction to project management with Microsoft's Visual Studio Team System. In particular, this module shows how project managers can use TFS to create and manage a software development project. It talks briefly about project methodology and how different methodologies are supported by TFS. As well as discussing how to use the Team Explorer tool to manage the project, it also explores how to integrate other related tools commonly used by project managers today, such as Microsoft Excel and Microsoft Project.
The chapter also talks about how TFS uses process templates to represent the core information about these methodologies and these templates can be customized. This module shows how to change the contents of an existing template or add new ones, amending such details as work items, work item queries, reports, document templates and process guidance.
Source Code Control: Introduction
Source code control, or revision control, is the management of revisions to pieces of information that makes up a project. Many applications make use of source code control to manage their code, documentation, project data and any other information that a project requires. TFS has a source control management system, entirely separate from Visual Source Safe (Microsoft's previous source control offering). A TFS project will typically have one or more source control folders associated with it. Each folder is a location where project items can be stored, and are created either during project creation or at a later stage as needed. The actual data that the source control system manages is held in a SQL Server database set up during the installation of Team Foundation Server. Project members can perform various actions on the source control repository, and in this chapter we will look at the basic mechanisms involved in source control. Members can check data into and out of source control. When checked out the data is associated with a client side 'workspace'. The workspace is an area on the client that holds checkout data. A given client may have multiple workspaces, this allows the clients to checkout different parts of the repository into different workspaces allowing clients (for example) to work with multiple versions of the code. Checkins are atomic and each checkin creates a new changeset. A changeset is a snapshot of all the files in the folder at the time this change was committed, each changeset is given a number (the changeset version). Users can checkout the latest version from the repository or can checkout a specific changeset. Changesets can also be labeled and users can checkout a given labeled version of the repository, users can also check out a version that was checked in on a specific date. All the above work can be done with the Project Explorer, Microsoft also supplies a command line tool called tf.exe and in this chapter we will take a first look at that tool.
Source Code Control 2: Advanced Topics
One of the features that Microsoft provides is the ability to 'branch' the source control repository. A branch is essentially a copy of the repository and branching allows a developer to work on new features without changing the current version that can still be worked on by other developers within the group. We will examine how branching is performed and how to manage branches as a user. Changes a developer makes in a branch may need to be added back into the main source control tree or indeed into another branch, this process is called merging. Microsoft has also introduced a concept that is new to source control, the idea of Shelving. The concept behind shelving is that a developer may be working on changing code and is then asked to work on something else. Rather than save the current changes locally and risk losing them, or check them back into source control when they are not finished, a developer can 'shelve' the changes. Shelves are essentially named branches that belong to a developer. They can be re-checked out by the person that created the shelve or by another user. Shelves are useful in many scenarios during the lifetime of a project and will be examined in detail. Finally, this module looks at how source control can be customized by writing and installing custom check-in policies.
Day 2
Test-Driven Development and Unit Testing
In recent years, unit testing has become recognized as a very important part of the software development lifecycle. A new style of development, Test Driven Development (TDD), has also come to the fore. In this chapter we will examine how Visual Studio supports TDD. We will start by explaining unit testing and defining what a unit test actually is. We will then look at writing unit tests in Visual Studio in particular looking at the attributes that are used when defining a 'test case' and how to write code to determine whether or not a test has succeeded or failed. We examine how to execute and debug tests and how to view test results. We also examine other areas of the test process such as checking for exceptions and writing code to initialize the test. Visual Studio also allows us to generate tests for already existing code; we will look at that process and at the generated test code. We may also have a need to test private methods. Visual Studio can generate stub code to test private methods. This chapter will examine that code and how it should be used within the test project. When testing it is important all code is tested, but how does a developer know that all the code in a project has been exercised?
Data Driven Testing, Code Coverage And Test Impact Analysis
When testing a specific method you will often want to test the method with different data. For example you want to test 'edge' conditions (values such as 0, +INF or -INF when dealing with integers). While this can be done by writing multiple tests it is also possible in Visual Studio to do this using a 'Data Driven' test. In a data driven test the test data is stored in a database table and this table is specified during the test process, each row in the table represents a different test case. In this talk we will show how to create the database, how to specify the table and columns within that table to use and how that data is passed to the test. We will also discuss the thorny issue of how to manage this database.
Visual Studio offers the ability to instrument code to show which code has been executed and which has not. In this chapter we will show how to configure a test run to also execute the code coverage engine.
Related to this Visual Studio has the ability to work out which tests have been affected once code has changed; this is called Test Impact Analysis. This chapter covers how to turn that capability on.
Inversion of Control
Inversion of Control is a mechanism that allows components in s software system to be very loosely coupled. It is achieved by configuring components to use dependency injection. This is vital if you want to be able to test code.
In this chapter we will look at the latest version of Microsoft's Inversion of Control (IoC) container called Unity. We will examine how to best use the container through configuration and code.
Day 3
Doubles and Mocking
Sometimes when testing code you have to be able to replace complex parts of the system under test, such as a database. In this chapter we will look at using Rhino Mocks to let us do this. Rhino has various styles of mocking from letting us create stubs to let us return data and creating dynamic mocks to ensure certain calls are made. We will couple the mocking tools with the IoC container to understand how to create good unit tests
Code Contracts
Visual Studio 2010 introduces Code Contracts to the .net development world. Code contracts let us provide pre and post conditions for any method in our code. These conditions can be checked at runtime, but more interestingly they can also be checked at 'compile' time, providing an extra level of insurance for our code.
This chapter looks at how to install the tooling for code contracts, how to write code contracts to set up pre and post conditions and how to use code contracts to their full.
Static Code Analysis
Syntactically correct code that passes all the compiler checks may still have issues that need to be resolved. If best practices weren't employed then code may not perform well, may not be scalable or may not be secure. Such code is an accident waiting to happen later on in the project lifecycle. For this reason, code needs to be reviewed. Visual Studio 2010 Team Edition for Software Developers has a rule-based code analysis tool built in that allows code to be reviewed early and often during development thus saving time and resources later on in the project lifecycle. This module shows how to effectively use code analysis, and explains how it is an integral part of the build process, how it integrates with aspects of Visual Studio Team System and how custom rules can be written and deployed to enforce the coding discipline in place for your organization.
Day 4
IntelliTrace
Applications go wrong. When developing code and something goes wrong it's easy to run the code through the debugger and look for the error.
There are also tools to provide post-mortem debugging, i.e. to help debug applications that crash or hung when actually running on a user's computer.
IntelliTrace provides a missing link. What happens when applications go wrong when being tested by your QA or acceptance test department? Those teams probably don't know how to use (and don't want to learn how to use) Visual Studio debugging. And while windebug and friends are great for post-mortem debugging it would be nice if we could gather more debugging information in such a controlled environment as our test environment. This is where IntelliTrace comes in; you can run the trace on a PC and have it gather all the data necessary to run a fairly complete debugging session.
Managing and Testing Databases with Visual Studio Team Edition for Database Professionals
Enterprise developers use databases constantly and these databases can become very large and often unwieldy. Visual Studio Team Edition for Database Professionals provides various mechanisms for managing and testing database definitions, data and code. Database schemas can be kept under source control and used to manage controlled updates of databases. Data can be compared across databases, for example to check that staging databases have the same data as a master database. Unit tests can be written to check that the functionality provided by your database actually does what it is supposed to. This chapter will cover each of these mechanisms.
Building Code: Team Build
On a large software team, it is often desirable to set up a public build environment where builds of the whole project are executed upon some trigger, such as may happen with continuous integration or with a nightly build. This module investigates how the Team Build component of Team Foundation Server manages public builds. It shows how the TFS Team Explorer can be used to set up different build configurations on different build servers - all version controlled using the TFS version control repository - and how builds can be executed. We cover how to schedule builds and how to use the continuous integration features of Visual Studio 2010 Team Build. It goes on to explain how builds can also be executed in response to a variety of triggers (e.g., source code check-in), how build types are defined using Windows Workflow and how they can be changed to suit the project.
