Visual Studio Team Test (VSTT) Fundamentals

Boundary value analysis is a fundamental testing technique that systematically tests parameters at their limits and edges. For API testing, this means testing minimum values, maximum values, values just beyond boundaries, and edge cases. Random inputs and sequences don't provide systematic coverage, and 'data points' is too vague.

When creating unit tests from source code, you select individual methods to test. Unit testing focuses on testing the smallest testable units - individual methods within a class - rather than entire classes or functions. You create test methods that verify specific method behaviors with different inputs.

In VSTT's testing framework, the [DeploymentItem] attribute specifies a file to be deployed to the test deployment directory before test execution. This attribute takes a file path (not a directory, function, or class) as its parameter, ensuring required files are available when the test runs.

Ordered Tests in VSTT allow you to define a specific execution sequence for tests. You arrange tests in the order they must run, and the test runner executes them sequentially rather than in parallel or random order. This is essential when tests have dependencies or must run in a particular sequence.

The Test Manager window in VSTT provides the interface for managing large test suites and executing multiple tests. It offers features for organizing tests, viewing results, and running batches of tests - capabilities that individual test view or case windows lack. This is the primary interface for test management at scale.

In VSTT (Visual Studio Team Test), ordered tests allow you to run tests in a specific sequence. Load tests are a distinct category of performance tests that cannot be nested inside ordered tests because they have their own configuration and execution model. Unit tests, web tests, and manual tests can all be included in ordered tests, but load tests are fundamentally different and run separately.

The Code Coverage Results window in VSTT provides detailed statistics about which code elements were covered during test execution, showing what percentage of your code was actually tested. Test case Results show individual test outcomes, Load Test Results show performance metrics, and Manual Test Results show manual test execution status - but only Code Coverage Results specifically show statistics about the code elements tested.

Comprehensive API validation requires checking all aspects: the return value verifies the output is correct, database updates confirm data persistence works properly, and exception handling ensures the API responds appropriately to errors. Each validation type catches different issues - return values check business logic, database updates verify data integrity, and exception testing confirms error handling.

Generic tests in VSTT use environment variables to specify paths to folders containing the target executable and other required files. This allows you to create tests that can adapt to different environments without hardcoding paths. Web tests run in browsers, Manual tests are executed by humans, and neither uses environment variables in this way - Generic tests are specifically designed to wrap external executables and tools.

Generic tests in VSTT follow the standard convention where a return value of 0 indicates success (Pass), while any non-zero return value indicates failure. This matches the common programming practice where 0 means successful execution and non-zero values indicate various types of errors. The test engine uses this convention to determine whether the external test executable passed or failed.

Database unit tests in VSTT are designed to test programmable database objects like Stored Procedures (SPs), functions, and triggers because these contain business logic that can be validated through testing. DDL statements (CREATE, ALTER, DROP) define database structure and are typically tested through integration or schema tests, while DML statements (INSERT, UPDATE, DELETE) are data operations that are better tested at a higher level.

Database unit tests in VSTT support multiple test conditions: Scalar Value checks verify specific return values from functions or procedures, Row count validates that queries return the expected number of rows, and Empty/not-empty result set conditions confirm whether a query returned any data. Each condition type serves different validation needs - scalar values test computed results, row counts verify data volume, and result set checks confirm data presence.

Test Impact View was introduced as a new feature in VSTS 2010 to help developers understand which tests are affected by code changes. It analyzes code coverage and dependencies to recommend which tests should be run after a code modification. Test View and Test List Editor existed in earlier versions, making Test Impact View the standout new feature in the 2010 release.

VSTT data-driven unit tests support XML and CSV files as data sources for test parameterization. These formats allow you to define multiple test cases that use different input values without writing separate test methods. XLS (Excel) files are not directly supported as data sources for data-driven tests in VSTT, making XML and CSV the correct combination of supported formats.

VSTT saves test results in .trx (Test Result XML) files after test execution. These files contain detailed information about test outcomes, execution times, error messages, and other test run metadata in XML format. While the content is XML-based, the specific file extension is .trx, not .xml. Test results are not stored in .trs files or directly in databases by default.

To consume a WCF service in a client or test project, you instantiate and use the generated ServiceClient proxy class, which implements the service contract and manages the underlying channel communication.

The Test Impact View in VSTT is specifically designed to show how code changes affect unit tests by analyzing code coverage data and dependencies. It identifies which tests may be impacted by recent code modifications and recommends which tests should be run. Test View shows all available tests, Test Management View handles test organization, and Test List view manages test lists - only Test Impact View focuses on the relationship between code changes and test impacts.

To use a WCF service in a test project, you use the "Add Service Reference" option which generates proxy classes and configuration for consuming the service. Add Reference is for .NET assemblies, Add Service as Existing Item adds files to the project, and Add Service as Existing Project adds entire projects - only Add Service Reference properly sets up WCF service connectivity with the necessary proxy generation and configuration.

svcutil.exe generates a service proxy class file (Service.cs) and an output configuration file (output.config) containing endpoint settings when working with WCF services. The other options either use incorrect filenames (Services.cs) or reference the wrong configuration file (App.config is the application's existing config, not the generated one).

SharePoint supports two primary deployment configurations: Standalone (where all components and a basic database reside on a single machine) and Server Farm (which allows databases, application servers, and web front-ends to scale across multiple servers).