Running Tests in Application Hosts
As described in Overview of Host Adapters, software testing in general and unit testing in particular should attempt to duplicate the runtime environment of the application that you are testing. In many circumstances, you can accomplish this by running tests under VSTestHost.exe, the default test host of Team Edition for Testers.
Using the default test host works especially well when you plan to run your application on the same operating system in which Visual Studio will test it. For example, you want to test an existing assembly on a known version of Windows on which a known version of the .NET Framework is installed.
When you use this approach to execute unit tests, Visual Studio creates a separate process for test execution, loads the test assembly by type name, and then reflects over the classes in the assembly. For all classes marked with the TestClass attribute, the system executes all methods marked with the TestMethod attribute. A reference to the production code assembly is built into the test assembly. Therefore, the production code assembly is implicitly loaded when the test assembly is loaded.
This default solution for executing unit tests is simple. The default test host uses its own process and loads both the test assembly and the production code assembly. But it does not cater to more specialized requirements. For example, it does not offer host services to the production code such as access to a required object model. Additionally, it depends on access to production-code assemblies at the time it loads the test assembly.
For this reason, other, more flexible, approaches are necessary. For descriptions of the approaches used for testing in other environments, see the following sections:
ASP.NET. Team Edition for Testers provides a built-in test host for testing ASP.NET applications.
Microsoft SQL Server. Because no solution is provided by Team Edition for Testers, you would have to create a custom host adapter for testing operations of Microsoft SQL Server.
Embedded devices and other platforms. Because no solution is provided by Team Edition for Testers, you would have to create a custom host adapter to run tests in these environments.
ASP.NET
For the following reasons, ASP.NET applications must be tested differently.
The production code assembly of an ASP.NET application is not built until runtime, which makes it impossible to build a test assembly that references the production code. This, in turn, introduces the following problems:
No implicit public-method access through a project-to-project reference. Production code should be loaded by the host in the same or equivalent context to how the code ordinarily executes. For example, web.config settings should be available to ASP.NET production code.
No IntelliSense support for test authoring. When authoring tests, IntelliSense against the production code should provide full fidelity for testable methods.
The production code assembly is not implicitly loaded at runtime. Production code should be properly initialized by the host so that the host and production code are hooked up correctly and objects are initialized correctly. For example, objects on an ASP.NET page are created and available as they are when the page is correctly loaded.
The solution for supporting ASP.NET unit tests is that Team Edition for Testers provides a special built-in test host for ASP.NET. This host makes the following possible:
ASP.NET unit tests are executed in the ASP.NET context. This makes objects such as HttpSessionState, HttpApplication, and HttpRequest available to the production code. You can configure the host to run unit tests for ASP.NET in either the local Visual Web Developer Web Server or in IIS.
In ASP.NET unit tests, page-specific objects are initialized correctly so that production code that handles page objects can execute correctly without throwing exceptions.
A compile-time reference cannot be made to the ASP.NET code because no assembly exists until the code is compiled by the server. This means that you cannot refer to production code through a normal project reference. The solution is that an ASP.NET unit test uses a production code accessor for all methods, even public ones. This also makes IntelliSense available.
The programming model for authoring ASP.NET unit tests is the same as the programming model for authoring unit tests against internal or private methods. The test author uses a production code accessor that wraps each production code method with an accessor that can late-bind and invoke public, internal, protected, or private methods.
For more information, see Overview of ASP.NET Unit Tests.
Microsoft SQL Server
You may be a database develoepr who has used the .NET Framework to write a C# stored procedure. The stored procedure is executed inside the SQL Server engine. This means that if you run a unit test for the stored procedure inside the default test host, the test cannot access tables and data. Instead, you must run the test in the SQL Server process to access whichever table and view objects and other stored procedures that your stored procedure requires.
Team Edition for Testers contains no built-in host for testing operations of Microsoft SQL Server. You would have to create a host adapter for this purpose.
Such a host adapter could consist of two pieces: one that runs in the agent and one the runs in Microsoft SQL Server. The part that runs in SQL Server is the piece that you are testing, the .NET stored procedure.
The sequence of events could be as follows:
The agent side of the host adapter invokes the stored procedure adapter.
The stored procedure adapter loads the test assembly and the test methods in the production code assembly. This assumes that the test assembly can reference the production code assembly. If the test assembly cannot reference the production code assembly, as is the case with ASP.NET, the stored procedure adapter can load the production code assembly and then load the test assembly and initialize its class accessor.
Embedded Devices and Other Platforms
As is the case for Microsoft SQL Server, Team Edition for Testers contains no built-in host for testing applications on a special platform or in a special environment other than ASP.NET. Therefore, to run tests in these ways, you would have to create a custom host adapter.
The host adapter abstracts the details of connecting to a running server. It does this by performing the following steps:
It loads the production code.
It loads the test adapter for the given test type.
It loads and calls the test code in the server context.
It gathers test results and returns them to the agent.