MSDN Magazine Launch Issue - February 15, 2008 - (Page 73) Figure 11 Common Base Class Defined namespace UnitTesting.Samples.TestConditions { public abstract class DataSetTestCondition : TestCondition { // } } namespace UnitTesting.Samples.TestConditions { [DisplayName(“Checksum”)] public class ChecksumCondition : DataSetTestCondition { // } } namespace UnitTesting.Samples.TestConditions { [DisplayName(“Expected schema” )] public class ExpectedSchemaCondition : DataSetTestCondition { // } } Figure 10 Shared Test Condition Configuration quickly find that they need to verify a resultset rather than a single value, so here I’ll build two additional test conditions. These two test conditions, plus the LoggingTestService, are additionally part of a new set of power tools for Visual Studio 2008 released by the Team System Data team. To download the new power tools, please see go.microsoft.com/fwlink/?Linkid=107300. The first test condition is ChecksumCondition. At design time, it generates a hash of the expected results. At execution time, the actual results are hashed and the resulting value is compared with the expected result. The second, ExpectedSchemaCondition, collects and stores the expected schema at design time. At execution time, the actual schema is compared with the expected schema. When utilizing test conditions, a user creates a database unit-test class and adds the test conditions from a list of available conditions (a reference to the assembly containing the new conditions is added automatically when the new test class is added to the project). The user can access the test condition’s configuration by pressing on the ellipses in the Configuration property. The resulting dialog, shown in Figure 10, allows the user to specify and execute the query that retrieves the expected data; in this figure, the data displayed is random (nonsensical) data generated by the DBPro Data Generator. When first displayed, the T-SQL from the test is provided in the textbox. The user can then modify the test code to reflect the query she actually wants and then click on the Retrieve button to execute the code against the server and display the results. Once the user is satisfied that the results are what was expected, she clicks OK, and the test condition configures itself accordingly. The user doesn’t have to interact with the condition any further. Now that you have an idea what the end result will look like, you can create these test conditions. When developing the previous test conditions, the bulk of the interesting code is in the designtime behavior. I will walk through the high points in the following section; the complete code is available at msdn.microsoft.com/ msdnmag/code08.aspx. Figure 12 UnitTesting.Samples.extensions.xml When defining a new test condition, I find that it is easiest to define the skeleton and registration of the condition first and verify that the skeleton works before developing the actual condition logic. Because the two sample test conditions are very similar, I defined a common base class, as you see in Figure 11. Once the project compiled, I then defined the registration XML file, called UnitTesting.Samples.extensions.xml, shown in Figure 12. I like to add the extensions file directly to the project and set it to automatically copy to the output directory so that it is easy to reference and use during development and deployment. The final step is setting up automatic deployment by copying the extensions file to the DBPro directory and installing the test conditions assembly into the Global Assembly Cache (GAC).This can be accomplished through a post-build step or by running a command prompt with elevated privileges. I used the following script in my project’s post-build step: set TargetNameVar=$(TargetName) set DevEnvDirVar=$(DevEnvDir) set WindowsSDKVar=$(ProgramFiles)\Microsoft SDKs\Windows\V6.0A copy /Y %TargetNameVar%.extensions.xml “%DevEnvDirVar%..\..\DBPro\*” copy /Y %TargetNameVar%.pdb “%DevEnvDirVar%PublicAssemblies\*” “%WindowsSDKVar%\Bin\gacutil” /if %TargetNameVar%.dll Defining the Test Condition Database Unit Testing launch2008 73 http://go.microsoft.com/fwlink/?Linkid=107300 http://msdn.microsoft.com/msdnmag/code08.aspx http://msdn.microsoft.com/msdnmag/code08.aspx
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.