Unit testing is one of the earliest phases of testing the application. In this phase the developers have to make sure that the unit of testable code delivers the expected output. It is extremely important to run unit tests to catch defects in the early stage of the software development cycle. The main goal of the unit testing is to isolate each piece of the code or individual functionality and test if individual method is returning the expected result for different sets of parameter values.

A unit test is a functional class method test by calling a method with the appropriate parameters, exercises it and compares the results with the expected outcome to ensure the correctness of the implemented code. Visual Studio 2012 has great support for unit testing through the integrated automated unit test framework, which enables developers to create and execute unit tests.

Visual Studio generates the test methods and the base code for the test methods. It is the responsibility of the developer to modify the generated test methods and customize the code for actual testing. The code file contains several attributes to identify the Test Class, Test Method, and Test Project. These attributes are assigned when the unit test code is created for the original source code. Here is the sample of the unit test code:

Once a unit test is created for a testable unit of code, the developers can use it with multiple combinations of input parameters to make sure the actual result is as per the expected result.

All the methods and classes generated for the unit testing are inherited from the Microsoft.VisualStudio.TestTools.UnitTesting namespace. This namespace is only used when the default Visual Studio integrated testing tool is used. This namespace contains many classes and attributes to provide enough information for the test engine to determine data source, test execution, execution order, deployment, and results.

Visual Studio also provides the flexibility to integrate unit testing tools such as Unit and XUnit for which the adapters need to be installed. After installing the tool, the respective namespaces can be used for generating calls and unit testing methods.

Manual testing is the oldest and simplest type of testing, but yet very crucial for software testing. The tester would be writing the test cases based on the functional and non-functional requirements and then test the application based on each written test case. It helps us to validate whether the application meets various standards defined for effective and efficient accessibility and usage.

Manual testing can be an alternative in the following scenarios:

The tested code hasn't stabilized sufficiently for cost effective automation.

We can create manual tests by using Visual Studio 2012 very easily. A very important step in manual testing is to document all the test steps required for the scenario with supporting information in a separate file. Once all the test cases are created, we should add the test cases to the Test Plan in order to run the test and gather the Test Result every time we run the test. The Microsoft Test Manager tool helps us in adding or editing the test cases to the Test Plan. The manual testing features supported by Visual Studio 2012 are as follows:

There are a lot of other manual testing features supported in Visual Studio 2012. We will see those features explained in Chapter 2, Test Plan, Test Suite, and Manual Testing.

Exploratory testing is an open approach to testing without any process and test cases. The only known fact is the user story. The objective of this testing is to test the existing application or feature, and to find any improvements required, defects, broken links, and familiarize with the existing system. This type of testing has been followed for many years, but there was no tool to support the testing and capture the defects and steps. It was a tedious process to document the steps and capture supporting screenshots.

The Microsoft Test Manager (MTM) has the new feature to perform the exploratory testing and capture the screenshots, test steps, test case, comments, attachments, and defects automatically. The testing actions are stored as test cases so that it is easy while retesting.

To start exploratory testing, open the MTM and navigate to Testing Center | Test |Do Exploratory Testing. Now by selecting a work item requirement and then clicking on Explore work item will associate the recording of the test with the work item. Any test cases or defects created during Exploratory session will automatically get linked to the work item. The following screenshot shows a sample Exploratory testing session started for a work item:

During Exploratory testing, all actions performed on the screen are recorded except the actions performed in MTM and Office applications. To change this setting, configure the settings in the Test Plan properties.

A detailed walk-through the Exploratory testing is covered in Chapter 12, Exploratory Testing and Reporting which talks about Exploratory testing and reporting.

Web performance tests are used for testing the functionality and performance of the web page, web application, website, web services, and a combination of all of these. Web tests can be created by recording the HTTP requests and events during user interaction with the web application. The recording also captures the web page redirects, validations, view state information, authentication, and all the other activities. All these are possible through manually building the web tests using Web test. Visual Studio 2012 provides Web performance test features, which capture all HTTP requests and events while recording user interaction and generating the test.

There are different validation rules and extraction rules used in Web performance tests. The validation rules are used for validating the form field names, texts, and tags in the requested web page. We can validate the results or values against the expected result as per the business needs. These validation rules are also used for checking the processing time taken for the HTTP request.

Extraction rules in Web performance tests are used for collecting data from the web pages during requests and responses. The collection of these data will help us in testing the functionality and expected result from the response.

Providing sufficient data for the test methods is very important for the success of automated testing. Similarly for web tests we need to have a data source from which the data will be populated to the test methods and the web pages will be tested. The data source could be a database or a spread sheet or an XML data source or any other form of data source. There is a data binding mechanism in Web tests which takes care of fetching data from the source and provides the data to the test methods. For example, a reporting page in a web application definitely needs more data to test it successfully. This is also called the data-driven web test.

Web tests can be classified into Simple Web test and Coded Web test. Both of these are supported by Visual Studio.

Coded UI Tests (CUIT) are the automated way of testing the application user interface. In any UI intensive application, the functionality of the application is verified manually through UI and this happens after the development. Next time there is any change to any of the backend functionality, the application should be retested again. CUIT helps us in saving time spent testing through UI multiple times manually. CUIT Builder helps us in recording the UI test step actions and then generates code out of it. After the test is created, we can modify the code and customize the actions and data values captured during recording.

A Coded UI Test generates several supporting files as part of the testing. The UIMap object represents the controls, windows, and assertions. Using these objects and methods we can perform actions to automate the test. The coded UI Test supporting files are as follows:

The following screenshot shows the Coded UI Test with the default files created for the test:

Load testing is a method of testing, which is used to identify the performance of the application under maximum workload. In case of a desktop or a standalone application, the user load is predictable, and thus easy to tune the performance, but in case of a multiuser application or a web application, it is required to determine the application behavior under normal and peak load conditions.

Visual Studio provides a load test feature, which helps in creating and executing load test with multiple scenarios. The following are the parameters set using the load test wizard:

If the application is a public-facing website or one with a huge customer base, then it is better to perform load tests with real or expected scenarios. The Visual Studio load test makes use of the Web test recording or the unit test during load Test Run.

The load test is always driven by the collection of Web and Unit tests. A web test is used to simulate the scenario of concurrent users using the website and making multiple HTTP requests. The load can be configured to start with a minimum number of virtual users and then gradually increase the user count to check the performance at multiple stages of user load until it reaches the peak user load.

A unit test can be included as part of the load test in case of testing the performance of a service or individual method to find out the servicing capacity and threshold for client requests. One good example would be to test the data access service component that calls stored procedure from the backend database and returns the results to the client application.

The load test captures the results of individual tests within the Test Run. This helps us to identify the failed tests and debug and analyze them later. The results of all load tests can be saved in a repository to compare the set of results and then take necessary measures to improve performance.

Visual Studio has the Load test analyzer to provide the summary and details of Test Runs from the load Test Result.

Load testing properties, working with tests, and analyzing the load Test Results are explained in detail later in this book in Chapter 7, Load Testing.

Ordered test is just a container which holds the order in which a sequence of tests should be executed. All required tests should be ready and available to get added to the ordered test. Each test is independent and there is no dependency here. It is just the sequence of execution that is maintained in the ordered tests.

Test execution and results follow the sequence defined in the ordered test. The result of individual test is maintained in the repository. We can check the results anytime and analyze it.

Reordering the tests, adding new tests, and removing an existing test from the order are all possible through the Ordered Test Editor in Visual Studio.

An ordered test is the best way of controlling and running several tests in a defined order.

Generic test is useful in testing an existing executable file. It's the process of wrapping the executable file as a generic test and then executing it. This type of testing is very useful when testing a third party component without the source code. If the executable requires any additional files for testing, the same can be added as deployment files to the generic test. The test can be run using the Test Explorer or a command-line command.

By using Visual Studio, we can collect the Test Results and gather code coverage data too. We can manage and run the generic tests in Visual Studio just like other tests. In fact, the Test Result output can be published to the Team Foundation Server to link it with the code built used for testing.