MSDN Magazine Launch Issue - February 15, 2008 - (Page 68) Figure 4 App.config In the third dropdown, you select a database to deploy prior to executing any tests. If you select a database project (and select the default configuration), a differencing build will be performed and the change deployed to the database specified in the execution connection string. If you have not made any changes, this is a quick operation (thanks to changes in DBPro SP1) because MSBuild and the deployment script detect that no changes have been made. After the tests have been executed, you can see the results of the database deployment by clicking on the hyperlink at the top of the Test Results tool window. In the very last dropdown, you select a data-generation plan that should be deployed prior to test execution. This plan will run every time your tests run, so you will want to configure a small amount of data to reduce the time it takes for your tests to actually begin execution. After you click OK on the dialog, the information is stored in the test project’s app.config file, as shown in Figure 4. Up to this point, I’ve shown you the major features exposed by the UI—now let’s drill into the actual code. be used to execute your test. This connection string will probably use Windows® authentication by default, but you can specify SQL Server authentication. If you do, the password will be stripped out, encrypted, and stored in the registry (the password will be retrieved from the registry during test execution). In the second dropdown, specify a different set of credentials for modifying and verifying database state. For instance, if you want to execute your tests using the credentials the application will use (for example, the Web tier communicating with the database), you may want to use a different set of credentials with higher privileges to verify the database state. All other scripts, including deployment and data generation, use this connection string. If you do not specify a connection string, the execution connection string is used. The unit-testing API was designed to meet your need to change or augment the way the test harness works out of the box. Microsoft expected that users would want to modify the code that’s generated, write their own test conditions, and replace the default test service with their own implementation. Figure 5 lists the classes that make up the database unit-testing API. (Also see msdn2.microsoft.com/microsoft.visualstudio.teamsystem.data.unittesting for more information.) The default instance of the test service is accessed through a static property on the DatabaseTestClass. If you would like to, you can replace the default implementation with your own and override any of the above implementations. There are several reasons why you may want to modify the generated Visual Basic or C# code. The two most common scenarios are to execute your Figure 5 Classes in the Database Unit-Testing API unit tests in a transaction or to take advantage of the unit-testing harness’s data-driven Class Purpose testing feature. TestCondition The base class for all test conditions used to verify test scripts. A subclass of Component, it supports a design-time and runtime execution. At design time, you configure the test condition with the values you expect during test execution, and at run time the test condition uses those design-time values to verify the actual test results. Modifying Generated Test Code Transactions DatabaseTestClass The base class for all database unit tests in Visual Studio. The definition of this class integrates into the Visual Studio design environment and is responsible for serializing the code in InitializeComponent. Encapsulates a connection to a database. This class is a component, a design-time representation of a database unit test. Instances of this class host the DatabaseTestAction instances that comprise one test. Represents the result of executing one batch during test execution. This class is a component. Instances of this class contain a script and a collection of test conditions. The default implementation of the test harness. It implements database deployment, data generation, creation of execution and privileged connection contexts, and test execution. ConnectionContext DatabaseTestActions ExecutionResult DatabaseTestAction DatabaseTestService Unit tests that are executed in a shared environment must be careful not to dirty the execution environment; modifying the expected data or schema could cause subsequent tests to fail unexpectedly. Authors of database unit tests must be especially careful because it is very easy to make this kind of mistake. That said, not surprising to any database developer, the way database unit-test authors avoid modifying the underlying database is through the use of transactions. Here I will show you three ways you can leverage transactions. Inside the executed T-SQL, use this transaction: 68 msdnmagazine Database Unit Testing http://msdn2.microsoft.com/microsoft.visualstudio.teamsystem.data.unittesting http://msdn2.microsoft.com/microsoft.visualstudio.teamsystem.data.unittesting
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.