What is VSTS?

Visual Studio 2005 Team System is a productive, integrated, and extensible suite of
lifecycle tools that enable greater communication and collaboration among software
development teams.

One of the features of VSTS includes:

• Setup Unit tests (replacing NUNit).

• Create and run manual tests, Web tests, and load tests.

The product is called Visual Studio Team Test

A client tool for those devoted to testing that enables them to design, manage, and
execute manual, unit and load tests. It is designed to aid in the process of software
development. VSTT enables

• Code generation of test method stubs.

• Running tests within the IDE.

• Incorporation of test data loaded from a database.

• Code coverage analysis once the tests have run.

Team Test

VSTS takes testing a step further than simple unit testing by making them available
in the Team Test product geared specifically for testers. This product enables testers
to execute the unit tests developers create in a systematic fashion to ensure that
code checked in by multiple developers’ passes previously constructed tests. This is
an example of another testing best practice referred to as regression testing.

Team Test goes even further by making testers first-class citizens of the project by
highlighting the importance of testing at the team level through a test authoring and
execution environment. That environment includes additional test types such as Web
Tests, Load Tests (similar to the tool Application Center Test tool that ships with
Visual Studio .NET 2003), Manual Tests, and Ordered Tests and test case
management all integrated into Team Foundation.
Advantages/Benefit of Unit Tests

• The unit tests serve as the first users of your system and will frequently identify
design issues or functionality that is lacking.

• A well-written test suite provides the original developer with the freedom to pass the
system off to other developers for maintenance and further enhancement.

• Cheaper cost - It is a component that comes along with the MS Visual Studio
IDE.

• Disciplined Development - Well defined deliverable for the developer and more
quantifiable progress. Often, just considering a test case will identify issues
with an approach/design.

• Facilitates change and Reduces code fragility – Unit testing allows the
programmer to refractor code at a later date, and make sure the module still
works correctly (i.e. regression testing).

• Simplifies integration - Unit testing helps eliminate uncertainty in the pieces

themselves and can be used in a bottom-up testing style approach. By testing
the parts of a program first and then testing the sum of its parts, integration
testing becomes much easier.

• Documentation - Unit testing provides a sort of "living document". Clients and

other developers looking to learn how to use the class can look at the unit
tests to determine how to use the class to fit their needs and gain a basic
understanding of the API.

• Relative cost to fix defects graph - The earlier an error is caught the cheaper
it is to fix.

It takes the typical developer time and practice to become comfortable with unit
testing. Once a developer has been saved enough time by unit tests, he or she will
latch on to them as an indispensable part of the development process.

Unit testing does require more explicit coding, but this cost will be recovered, and
typically exceeded, when you spend much less time debugging your application.

Writing effective unit tests

• Always separate your unit test assemblies from the code you are testing.
• Avoid altering the code you are testing solely to allow easier unit testing.
• Each test should verify a small slice of functionality. Do not write long
sequential unit tests that verify a large number of items.
• All tests should be autonomous. Avoid creating tests that rely on other tests
to be run beforehand.
 • Test both expected behavior (normal workflows) and error conditions
(exceptions and invalid operations).

Test-driven development

Test-driven development (TDD) is the practice of writing unit tests before writing the
code that will be tested. TDD encourages following a continuous cycle of
development involving small and manageable steps.

The most common way to determine success in unit tests is to compare an expected
result against an actual result. The Assert class features many methods that enable
you to make these comparisons quickly.

Team System Unit Test Assertions

Assert.AreEqual, Assert.AreNotEqual
Assert.AreNotSame, Assert.AreSame
Assert.Equals
Assert.Fail
Assert.Inconclusive
Assert.IsFalse
Assert.IsInstanceOfType
Assert.IsNotInstanceOfType
Assert.IsNotNull
Assert.IsNull
Assert.IsTrue

The Microsoft.VisualStudio.TestTools.UnitTesting namespace includes a class,

Collection Assert, containing useful methods for testing the contents and behavior
of collection types.

Similar to CollectionAssert, the StringAssert class contains methods that enable

you to easily make assertions based on common text operations. The following table
describes the methods supported by StringAssert.
The unit test framework offers attributes to identify such methods. They are
grouped into three levels: Test, Class, and Assembly. The levels determine the scope
and timing of execution for the methods they decorate. The following table describes
these attributes.

Some other Attributes are

• TestClass
• TestMethod
• Description
• Ignore
• ExpectedException

The generated test project contains four files related to testing.

File Name Purpose

AuthoringTest.txt Provides notes about authoring tests including

instructions on adding additional tests to the
project.

LogonInfoTest.cs Includes generated test for testing the

LogonInfo() constructor along with methods
for test initialization and cleanup.

ManualTest1.mht Provides a template to fill in with instructions

for manual testing.

UnitTest1.cs An empty unit test class skeleton in which to

place additional unit tests.
Steps to Create a Unit Test Case

1. Right click on a method in the solution.

2. By default, the Output project setting is for a new Visual Basic project, but C#
and C++ test projects are also available. We will select Visual C# and click
the OK button, followed by entering a project name.

3. Implement the code in the test method.

4. Run the Test

• To enable this action, we need to right-click on the project within the

solution explorer and click Set as Startup Project. Next, use the
Debug->Start (F5) or Debug->Start without Debugging (Ctrl+F5)
menu items to begin running the tests.

5. Test Results window will be shown after executing all tests.

Example:

1. Open Visual Studio IDE

Click Start > Programs > Microsoft Visual Studio 2005 >Microsoft Visual Studio 2005

2. Creating a Sample C# Project

File-->New Project-->Chose from Templates as below

3. Add a simple "add" method to the code. This method accepts 2 arguments,
adds them and returns the total.

4. Create Unit Test for "add" method by right clicking on the method
5. This will display a dialog box for generating unit tests into a different project (see
Figure below). By default, the Output project setting is for a new Visual Basic
project, but C# and C++ test projects are also available. For this article, we will
select as C# project click the OK button.

6. Now enter a Test project name of computeTest for the project name.
7. The generated test project contains following files related to testing.

File Name Purpose

AuthoringTest.txt Provides notes about authoring tests including instructions on
adding additional tests to the project.
computeTest.cs Includes generated test for testing the add(x,y) method along with
methods for test initialization and cleanup.

8. In addition to some default files; the generated test project contains references to
both the Microsoft.VisualStudio.QualityTools.UnitTestFramework and the computation
project, which the unit tests are executing against. The former is the testing
framework assembly the test engine depends on when executing the unit tests. The
latter is a project reference to the target assembly we are testing.

There are two important attributes related to testing with Team Test.

First, the designation of a method as a test is through the TestMethodAttribute

attribute. In addition, the class containing the test method has a
TestClassAttribute attribute.

Both of these attributes are found in the:

Microsoft.VisualStudio.QualityTools.UnitTesting.Framework namespace.

Team Test uses reflection to search a test assembly and find all the TestClass
decorated classes, and then find the corresponding TestMethodAttribute decorated
methods to determine what to execute.

One other important criterion, validated by the execution engine but not the
compiler, is that the test method signature be an instance method that takes no
parameters.

The test method AddTest() instantiates the target computaion class before checking
for assertion.

When the test is run, the Assert.Inconclusive() provides an indication that it is

likely to be missing the correct implementation.
9. Providing input values to test method

Updated addTest() Implementation after editing to provide input values

Note that the checks are done using the Assert.AreEqual() method.

10. Running Tests:

Right-click on the computeTest.Test project within the solution explorer and click Set
as Startup Project. Next, use the Debug->Start (F5) or Debug->Start without
Debugging (Ctrl+F5) menu items to begin running the tests.

To view additional details on the test, we can double click on it to open up the
AddTest() Results:

Please note that the message in the assert statement does not appear for a
"passing" test. It appears only when a test fails along with "Expected" and "Actual"
values. Lets assume that by mistake (even though it’s highly unlikely) we have put
total=x*y instead of x+y in source code file. Let's try to run the same test and see
the results:
How to do a Web testing for a login page

1. Create a login web page.

• Create a class dbaccess.cs inside the project.

• Create a method dbConnect() to connect to the database, it will return true
if successful.
• Create a method IsUserExits(sUsername,sPassword) to check wheater the
user exists or not.

Create the unit test case for dbConnect and IsUserExists

Making a connection to the Database:

In Test menu click on Windows > Test View. In Test View, right Click on method
name --> Properties --> Chose Data Connection String, Data Table Name and Data
Access method as sequential or random.
2. Creating a Test Project.

We create the test project just as we would any VSTS unit testing project. The steps
below outline the process. In order to successfully record a test, the website must be
running.

1. Right-click the solution and click Add Project.

2. Choose the programming language and select the Test node.

3. Name the project Logintest.Test

There is nothing specific about creating a project that defines it as a Web test
project. Instead, the test files added to the project are specifically Web test files
rather than another test file type (unit test, load test, manual test, generic test, and
so on). The next step, therefore, is to add a Web test case. Since we are not going to
use any of the other types of test files added to a test project, these can be deleted.

1. Right-click the project, click Add, and then click Web Test. This opens up a
browser with a special Web Test Recorder explorer bar.
 Recording a Web test case

2. On the address bar, enter the URL of the login web page, including the port
selected by the ASP.NET Development Server. Browsing to this location will be
recorded in the Web Test Recorder explorer bar as would any other URLs that
are entered.

3. Enter the user name and password that were added earlier. Upon clicking the
Login button, another entry will be recorded, along with the form post
parameters. That way, when the test is run, the same data will automatically
be sent. Even the X and Y coordinates of where the button was clicked are
saved as part of the test, since these are also submitted as part of the
request.
4. Add additional steps to the test by logging out of the site and then re-
attempting the login with invalid credentials.
5. Once the desired tests have been recorded, close the browser windows and
save the test.

Automatically, the project will now include the Web test case file along with each of
the recorded requests.
Viewing a recorded Web test case

Selecting any of the nodes within the WebTest tree will allow you to modify the data
inside the Properties window

Running a Web Test Case

After recording a test we are ready to begin executing it. To execute all the tests
within a project, simply run the project. This will open up the Test Results windows
and mark each test as pending while it is in progress and Passed/Failed once
execution completes.

Request Rules

Although checking for valid hyperlinks on a response page is a useful feature, it is

not sufficient in validating that the page is functioning correctly. For example, upon
entering valid credentials, the Web test needs to verify that the login was successful.
Similarly, when the credentials are invalid, we need to check that an appropriate
error message is displayed on the page. To support this, each Web request can
include extraction rules and validation rules.

Extraction Rules
Extraction rules capture a response value so that at a later time the value can be
used within a request. Rather than parsing the entire HTTP response manually, the
extraction rules provide a means of focusing in on a particular data item within the
response. The extracted data item can then be validated or used again in a
subsequent post back. Our recorded example automatically added an extraction rule
when we logged on.
The rule is an ExtractHiddenFields rule whose data is posted back in the second
request of the Web test case. During the subsequent request, this data is submitted
back in a hidden field on the page. Other extraction rule options are
ExtractAttributeValue, ExtractHttpHeader, ExtractRegularExpression, &
ExtractText.
Validation Rules

Validation rules allow the test writer to examine the entire HTTP response and verify
that it is correct. For example, valid credentials should cause the welcome! message
to appear in the HTML response. A validation rule that checks for these items in the
response should be added. The validation rules verify that this text appears
somewhere within the response body.

If a particular rule fails, the request will be marked as failed, and the Details tab will
provide an explanation for what failed.

This type of validation rule is a ValidationRuleFindText. It searches the entire

response body, looking for the specified text. In order to handle complex searching,
regular expressions are supported as part of ValidationRuleFindText.
In addition to ValidationRuleFindText, built-in validation rules include
ValidationRuleRequestTime, ValidationRuleRequiredAttributeValue, and
ValidationRuleRequiredTag.

Binding Test Data to a Data Source

Both validation and extraction rules provide for text entry within the Properties
window of virtually every node. However, what makes Visual Studio Web Test
powerful is the fact that the text can be pulled from a database.
To test using a data source, click the Add Data Source button on the toolbar of the
Web test. In the ensuing dialog box, specify an OLE DB Provider as Microsoft OLE DB
Provider for SQL Server. Click on Data Links to enter the data source, authentication
method and database name.

Once a test has been configured with a data source, it is necessary to return to the
Edit Run Settings dialog box and change the run count to one run per data
source row. In this way, the test will repeat for each row in the newly configured
data source, and during each run, the parameters associated with the data source
will be assigned the value in the column for the particular row.
Generating Web Test Code

Included on the toolbar for a web test case is a Generate Code button. Clicking this
button prompts for a test name, and then generates a CS/VB file corresponding to
Web case. The generated code includes each validation and extraction rule that may
have been added.