Document-level customizations for Word 2007 and Word 2010
One of the ways to “Refresh the document from within the Word(e.g. right click on document and click Refresh) using document-level customizations for Word 2007 and Word 2010“
This post will focus on Charts. I’ve added the samples to generate/refresh charts using OpenXML. The screenshot below displays the template having Scatter chart and Line chart and the document generated out of this template using this utility.
Word 2010 Template having Charts –> Generated documents with Charts refreshed:
Code Changes:
Class diagram for Chart specific classes is displayed below
“SampleDocumentWithTableAndChartsGenerator” is the sample that shows how to refresh template having Scatter and Line charts. The code snippets are displayed below
“RefreshCharts” method is added to DocumentGenerator class
/// <summary>
/// Refreshes the charts.
/// </summary>
/// <param name="mainDocumentPart">The main document part.</param>
In this post I’ll discuss about writing unit tests using Pex and Moles. Pex and Moles are Visual Studio 2010 Power Tools that help Unit Testing .NET applications.
Pex automatically generates test suites with high code coverage. Right from the Visual Studio code editor, Pex finds interesting input-output values of your methods, which you can save as a small test suite with high code coverage.
Moles allows to replace any .NET method with a delegate. Moles supports unit testing by providing isolation by way of detours and stubs i.e. Generate a Mole type from the original type and redefine its behavior using delegates.
I’ll explain the steps to generate unit tests for a project which calls a WCF service. Pex will be used to generate unit tests. Moles will be generated to isolate the external dependency(WCF proxy) and behavior will be redefined using delegates.
The projects inside the sample solution are
DemoService: This project is a WCF Service.
DemoLibrary: This project is a Class library and service reference to DemoService has been added. Unit tests will be generated for this project.
ConsoleApp: This project is a Console application.
DemoLibrary.Tests: This is a Test project and contains unit tests for DemoLibrary.
The solution structure is displayed below
DemoLibrary calls DemoService though proxy as displayed in the Layer diagram
I’ll now discuss in brief the code snippets of each project
WCF Service(DemoService): This service provided only a single operation
[ServiceContract]
public interface IDemoService
{
[OperationContract]
string Search(string criteria);
}
WCF Service Client(DemoLibrary): It calls the Search method of DemoService through proxy as displayed below
/// <summary>Test stub for GetResults(String)</summary>
[PexMethod]
public string GetResults([PexAssumeUnderTest]Search target, string s)
{
string result = target.GetResults1(s);
return result;
// TODO: add assertions to method SearchTest.GetResults(Search, String)
}
}
There is an external dependency(GetResults makes a service call though the WCF Proxy) so “Run Pex Explorations” will not generate unit tests as displayed below
In order to isolate the external dependency we need to generate Moles before running Pex Explorations. Moles will be generated for DemoLibrary and System.ServiceModel assemblies and behavior will be redefined using delegates. There are two ways to generate a mole for an assembly. I’ll show you both the approaches
Visual Studio: This is the easiest way.
Right click on the reference and generate Moles for that assembly as displayed below.
A .Moles file will be added to the project. Build the project and Moles.dll will be added to MolesAssemblies folder as displayed below .
Command Prompt: Moles can be generated from the command prompt.
Run the moles.exe and specify the assembly path for which Moles needs to be created.
Copy the generated assembly to the Project and add reference to it.
Similarly as explained above we need to generate Moles for System.ServiceModel assembly. For Visual Studio 2010 SP1 this may fail with error message “The type or namespace name ‘IHttpCookieContainerManager’ does not exist in the namespace ‘ssm::System.ServiceModel.Channels’ (are you missing an assembly reference?)”. This step however works fine for Visual Studio 2010. The fix is to exclude the type i.e. ‘IHttpCookieContainerManager’ from StubGeneration as displayed below
The next step is to Mock the Service call(redefine behavior using delegates) and add Asserts as displayed in code snippets below
/// <summary>Test stub for GetResults(String)</summary>
[PexMethod]
public string GetResults([PexAssumeUnderTest]Search target, string s)
Run Pex Explorations to generate unit tests for GetResults method as displayed below
Unit tests will be added to the Test Class as displayed below
Go to Test View and Run the unit tests as displayed below
Summary:
In a similar way we can extract out external dependencies using Moles and then run Pex Explorations. A few examples of external dependencies can be data layer, UI layer, server calls etc. You can read more about Pex and Moles at http://research.microsoft.com/en-us/projects/pex/.
List of functionalities that can be achieved using the utility/source code
Description regarding Samples provided with utility
New samples added in this update
In this part I’ll discuss about the sample that shows one of the ways to “Refresh the document from within the Word(e.g. right click on document and click Refresh) using document-level customizations for Word 2007 and Word 2010“. On click of Refresh Document the content of the document is refreshed as displayed below
Project “WordDocumentGenerator.WordRefreshableDocumentAddin” has been added to the utility for this sample. The steps followed for creating this sample are listed below
Added a new Word 2010 Document project as displayed below
Updated the document by adding the content controls as displayed below
Added a new Command bar button i.e. “Refresh Data” to the Command bar. On click of this button the document will be refreshed. The common scenario will be to refresh data from the Service. “WordDocumentGenerator.WordRefreshableDocumentAddin” is the document level customization project. This project references “WordDocumentGenerator.Library” and “WordDocumentGenerator.Client” projects.
The code snippet to add a new Command bar button is
This is the second post of this series. The previous post can be read at Part 1. The next post can be read at Part 3. The code is available for download at Utility Source Code.
Document generation using Content Controls and Open XML 2.0 SDK
Creating Word templates
Implementation and Samples
In Part 3 I have explained one of the way to “Refresh the document from within the document(e.g. right click on document and click Refresh) using document-level projects for Word 2007 and Word 2010“
In this post I’ll discuss
List of functionalities that can be achieved using the utility/source code
Description regarding Samples provided with utility
New samples added in this update
The sample document generators are discussed later. The functionalities that can be achieved using the utility/source code are: Document Generation
Generate document from a Word template using content controls as place holders and populate controls with data(Object)[SampleDocumentGenerator, SampleRefreshableDocumentGenerator, SampleDocumentWithTableGenerator]
Generate document from a Word template using content controls as place holders(data bound content controls) and populate controls with data(Object is serialized to Xml). [SampleDocumentGeneratorUsingDatabinding, SampleDocumentWithTableGeneratorUsingDatabinding, SampleDocumentGeneratorUsingXmlAndDatabinding]
Generate document from a Word template using content controls as place holders and populate controls with data(XmlNode)[SampleDocumentGeneratorUsingXml]
Generate document from a Word template using content controls as place holders(data bound content controls) and populate controls with data(XmlNode) [SampleDocumentGeneratorUsingXmlAndDatabinding]
Refresh the document from within the document(e.g. right click on document and click Refresh) using document-level projects for Word 2007 and Word 2010 [Explained in next post i.e. Part 3]
Generate document that can be
Standalone: Once generated document cannot be refreshed.
Refreshable: Once generated document can be refreshed. Content controls will be added/updated/deleted and content control’s content will be refreshed as per data.
Append documents using AltChunk
Protect Document
UnProtect Document
Removal of Content Controls from a document while keeping contents
Removal of Foot notes
Ensuring the each content control has unique Id’s by fixing the duplicate Id’s if any for a document
Serializing an Object to Xml using XmlSerializer(Used for document generation using data bound content controls as serialized object is written to CustomXmlPart)
Content Controls
Set text of a content control(not applicable for data bound content controls)
Get text from a content control(not applicable for data bound content controls)
Set text of content control while keeping PermStart and PermEnd elements(not applicable for data bound content controls)
Set Tag of a content control
Get Tag of a content control
Set data binding of a content control
Set text of a data bound content control from CustomXmlPart manually. This is helpful in cases when CustomXmlPart needs to be removed and this copies the text from the CustomXmlPart node using XPath.
CustomXmlPart
Adding a CustomXmlPart to a document
Removing CustomXmlPart from a document
Getting CustomXmlPart from a document
Add/Update a Xml element node inside CustomXmlPart. This is required
To keep Document related metadata e.g. Document type, version etc.
To make the Document self-refreshable. In this case the container content control is persisted inside a Placeholder node, the first time document is generated from template. Onwards when refreshing document we fetch the container content control from CustomXmlPart
Saving the Xml e.g. serialized object which will be the data store for data bound content controls
Sample Generators:
SampleDocumentGenerator: This sample shows how to generate a non-refreshable document from a template. The content controls are populated using C# code i.e. not using data bound content controls. It covers both direct assignment as well as recursive controls. The screenshot is
SampleRefreshableDocumentGenerator: This sample shows how to generate a refreshable document from a template. The content controls are populated using C# code i.e. not using data bound content controls. This is similar to SampleDocumentGenerator in implementation. Only difference is the generated document can be refreshed in this case. The screenshot is
SampleDocumentWithTableGenerator: This sample shows how to generate a refreshable document from a template having Table. The content controls are populated using C# code i.e. not using data bound controls. This is similar to to SampleRefreshableDocumentGenerator in implementation. Only difference is the template has an additional table. The screenshot is
SampleDocumentGeneratorUsingDatabinding: This sample shows how to generate a refreshable document from a template using data bound content controls. This requires that each of the placeholder(template’s content control) has a predefined XPath. The generated document is similar to SampleRefreshableDocumentGenerator.
SampleDocumentWithTableGeneratorUsingDatabinding: This sample shows how to generate a refreshable document from a template having table using data bound content controls. This requires that each of the placeholder(template’s content control) has a predefined XPath. The generated document is similar to SampleDocumentWithTableGenerator.
SampleDocumentGeneratorUsingXml (New): This sample shows how to generate a document from a template using XmlNode as data. This approach shows that a generic generator can be created which requires Xml as data. This requires that XPath for Tag as well as content needs to be provided. The content controls are populated using C# code i.e. not using data bound controls. It covers both direct assignment as well as recursive controls. The generated document is similar to SampleDocumentGenerator.
SampleDocumentGeneratorUsingXmlAndDatabinding (New): This sample shows how to generate a document from a template using XmlNode as data and data bound content controls. This approach shows that a generic generator can be created which requires Xml as data. This requires that XPath for Tag as well as content needs to be provided. It covers both direct assignment as well as recursive controls. The generated document is similar to SampleDocumentGenerator.
List of functionalities that can be achieved using the utility/source code
Description regarding Samples provided with utility
New samples added in this update
In Part 3 I have explained one of the way to “Refresh the document from within the document(e.g. right click on document and click Refresh) using document-level projects for Word 2007 and Word 2010“
The purpose of creating this utility was to use the Open Xml 2.0 SDK to generate Word documents based on predefined templates using minimum code changes. These documents can either be refreshable or non- refreshable. I’ll explain this difference later. Also there is no dependency that Word should be installed.
A few samples for generating Word 2010 documents have been provided. The screenshots below display the sample template and the document generated out of this template using this utility.
Word 2010 Template –> Generated Document:
Word 2010 Template –> Generated Document –> Refreshed Document:
Document Refresh from within Word –> Refreshed Document:
Template Design:
The sample templates are inside “WordDocumentGenerator.Client\Sample Templates” folder. A content control as displayed below can have Title and Tag properties.
The logic is to have a tag property of a content control and then populate data using that placeholder. This means every content control inside a Word template will have a different Tag.
As per image above the tag of the content control is “PlaceholderNonRecursiveB”. During document generation we can assign (not mandatory) a unique Id e.g. Guid of a record to make the tag unique e.g. “PlaceholderNonRecursiveB:Guid”. Let’s say that we have an Id and Name field. Thus the Name will be the content of the control and tag will be “PlaceholderNonRecursiveB:Id”. As per Word 2010 the Tag maximum length is 64.
In code we map the tag to the PlaceHolderType enum.
public enum PlaceHolderType
{
None = 0,
Recursive = 1,
NonRecursive = 2,
Ignore = 3,
Container = 4
}
There can be multiple types of PlaceHolders
Recursive: This type corresponds to controls where there is 1:N relation between template and data i.e. one example will be repeating a list of Items.
Non-Recursive: This type corresponds to controls where there is 1:1 relation between template and data i.e. one example will be showing a User name.
Ignore: No action is required for these controls.
Container: This type is required only for refreshable documents. We save the container region in CustomXmlPart the first time document is generated from template. Next time onwards we retrieve the container region that was saved and refresh the document. This makes the document self-refreshable.
I’ve named the tags in “Test_Template – 1.docx” as per their PlaceHolder type to make it more clear.
Implementation:
As explained above the Tag property will used to bind data to this content control. The project “WordDocumentGenerator.Library” is the utility library. The project “WordDocumentGenerator.Client” shows how this library can be used to generate documents.
“DocumentGenerator” is the base class that needs to be inherited by the document generators. The sample generators location is “WordDocumentGenerator.Client\Sample Document Generators”.
The purpose of creating this utility was to use the Open Xml 2.0 SDK to generate Word documents based on predefined templates using minimum code changes. These documents can either be refreshable or non- refreshable. New samples will be added as per feedback.
Tools that are useful for creation of test data as well as ensuring that database schemas are synchronized
Data generation
Schema comparison
Data comparison
More about unit testing a database which include
Data driven unit tests
Pre, test and post scripts
Test conditions
Transactions
Data Generation Plan:
Test data is created for verifying the behaviour of database objects in a database project. Generating data that is appropriate for the schema of the database but unrelated to the production data helps protect the privacy or security of the production data. Data generation plan can be added to the database project as displayed below
When data generation plan is created for a database project, the plan is based on the schema of the project. If after creation of the plan schema changes, Visual Studio prompts to update the plan.
There are two types of templates available for creating data generation plan
Data Generation Plan: This template creates an empty data generation plan
Data Transform Plan: This template creates an data generation plan reusing data from another data source
Data generation plan Template:
Select the template i.e. Data Generation Plan and specify name and Add as displayed below
After you click Add you can customize various aspects of data generation plan in the Data generation plan designer as displayed below
Here three tables are displayed as I had three tables Event, EventPass and Student in my database project. The Related Table shows a dropdown only for EventPass table because EventPass has foreign key relation to Event and Student table. Please refer to first article for details.
You can choose Table and Rows to Insert in each table for all the tables provided for table that has related tables e.g. EventPass Related Table is set to None. If Related Table is chosen then you can specify the Ratio to Related Table and depending upon this ratio the Rows to Insert column will be populated.
You can preview as well as change the generator as displayed below
Once you are done configuring this plan go to Data –> Data Generator –> Generate Data as displayed below
Specify a new or an existing connection in the Connect to Database dialog that will appear next. Please note that you need to have the same schema in the database that you have specified for this else Data generation will fail. In this example my database is SampleDBTestData and it contains tables only. Once data generation is completed you can see the generate data in the database that you specified.
Data transform plan Template:
Select the Data transform plan template, specify name and Add as displayed below
I have highlighted the sections that can be configured in this dialog. Rest of the steps are same as discussed above i.e. once you are done configuring this plan go to Data –> Data Genarator –> Generate Data.
Schema Comparison:
Schema comparison is a powerful tool that is used to compare database schemas as displayed below
The result when source and target schema are same is displayed below
The result when source and target schema were somewhat different is displayed below
Data Comparison:
The data from two databases can be compared as display below
This concludes the first logical part.
Data driven unit tests
In order to write a data driven unit test two important characteristics that we use are
DataSourceAttribute: This attribute provides data source specific information for data driven testing and is available in assembly Microsoft.VisualStudio.QualityTools.UnitTestFramework
TestContext: This class is used to store information that is provided to unit tests and is available in assembly Microsoft.VisualStudio.QualityTools.UnitTestFramework
As displayed in code snippet I have marked the dbo_AddStudentTest with DataSource and TestMethod attributes and specified the provider type, connection string, table name and data access method as displayed below
The unit test script is expects the parameter “StudentName” which I’ll populate from the test data. The same example I provided in first article of this series I had declared the parameter in the script and hard coded value for that parameter inside the script. Now you can drive unit tests from the test data. The unit test script for this test is displayed below.
<add name ="sqlDataSource" connectionString="sqlDataCon" dataTableName="EmployeeData" dataAccessMethod="Sequential"/>
</dataSources>
</microsoft.visualstudio.testtools>
and mark the Test method as displayed below
[DataSource("sqlDataSource")]
[TestMethod]
publicvoid dbo_uspAddStudentTest()
{
}
Common, Pre, Test and Post scripts:
You can specify Common scripts(common to all tests), Pre and Post scripts to a test in test editor. By default these are optional. The order of execution of these scripts is
The context of these are also different i.e. TestInitializion, Pre Test script, Post Test script, TestCleanup execute having PrivelegedContext whereas Test script executes having ExecutionContext.
Test Conditions:
I have discussed the test conditions in previous articles. In this article I’ll show two properties i.e. Configuration and Enabled. Enabled exist across all test conditions. You can enable/disable a test condition using this. Configuration property exists for Expected Schema and Data Checksum test conditions. For these conditions you need to configure the result you are expecting by clicking the button as highlighted below
You can define a custom test condition to verify the behaviour of a database object in ways that the built-in conditions do not support. Please read this msdn article for more details Define Custom Conditions for Database Unit Tests
Transactions:
There are three ways through which we can specify transactions as listed below
Inside Transact-SQL
ADO.NET Transactions: Transactions can be implemented by adding code snippet to the test method as displayed below
This only works if there are no pre and post test scripts for an unit test. This is because Pre and Post scripts are executed having PrivelegedContext where as Test script is executed having ExecutionContext
System.Transactions: Transactions can be implemented by adding code snippet to the test method as displayed below
using (TransactionScope scope = new System.Transactions.TransactionScope(TransactionScopeOption.Required))
In this case we have to enlist the transaction as we have two different contexts i.e. PrivelegedContext and ExecutionContext. This means if these we need to have distributed transaction coordinator service running as we are having transaction across two different connections.
This completes the series “How to unit test SQL Server database using Visual Studio 2010”. Please share the feedback so that I can improve/rectify the series.
del.icio.us Tags: Visual Studio 2010,SQL Server 2008,Unit Test,Schema Comparer,Data Comparer
In this article I will explore the important features that can be configured to build comprehensive database unit tests. The two assemblies that are the backbone for database unit testing are
Microsoft.VisualStudio.QualityTools.UnitTestFramework: This assembly is the testing framework assembly the test engine depends on when executing the unit tests. I won’t get into details of the parts of this assembly and focus on some the the important attributes that are required to execute an database unit test.
Microsoft.Data.Schema.UnitTesting: This assembly provides the classes required to create and execute database unit test. In this blog I’ll focus on this assembly.
In this article I’ll dig deep into these two assemblies and explore the various components of these assemblies that are used to execute unit test for a database.
I’ll start with the Database Unit Test Designer and then move on to explaining various components.
Database Unit Test Designer:
I have highlighted the various options available in Database Unit Test Designer and added short description as displayed below
The scripts that are created are stored in the resource file.
I’ll now discuss the important components of the Unit Testing Ecosystem which reside inside the assemblies
This namespace supplies classes that provide unit testing support. This namespace contains many attributes that identify test information to the test engine regarding data sources, order of method execution, program management, agent/host information, and deployment data.
I will touch upon the important attributes and classes that are required by the test engine to execute unit tests.
TestClassAttribute: The class containing test methods should be marked with this attribute else the tests won’t execute. This attribute can only be applied to a class.
AssemblyInitializeAttribute: Method marked with this attribute will be run prior to methods marked with ClassInitializeAttribute, TestInitializeAttribute, and TestMethodAttribute attributes. This attribute can only be applied to a method. Only one method in an assembly may be decorated with this attribute. An example of usage of this attribute is setting up database based upon setting from a configuration file i.e. deploying database, generating data.
AssemblyCleanupAttribute: Method marked with this attribute will be run after all the test methods in that assembly will execute i.e. after methods marked with TestMethodAttribute,TestCleanupAttribute and ClassCleanupAttribute attributes. This attribute can only be applied to a method. Only one method in an assembly may be decorated with this attribute. This method won’t execute if there is any exception in the method marked with AssemblyInitialize attribute.
ClassInitializeAttribute: Method marked with this attribute will run only once in the entire test. This attribute can only be applied to a method. This method runs before the method marked with TestInitialize attribute and after the method marked with AssemblyInitialze attribute. A class can have only one method marked with this attribute.
ClassCleanupAttribute: Method marked with this attribute will run only once in the entire test. This attribute can only be applied to a method. This method runs before the method marked with AssemblyCleanup attribute and after the method marked with TestCleanup attribute. A class can have only one method marked with this attribute. This method won’t execute if there is any exception in the method marked with ClassInitialize attribute.
TestMethodAttribute: Test method should be marked with this attribute else method won’t execute. This attribute can only be applied to a method.
TestInitializeAttribute: The method that is marked with this attribute runs before each test is executed. This method runs before methods marked with TestMethod attribute and after method marked with ClassInitialize attribute. This attribute can only be applied to a method. A class can have only one method marked with this attribute.
TestCleanupAttribute: The method that is marked with this attribute runs after each test is executed. This method runs before method marked with ClassCleanup attribute and after methods marked with TestMethod attribute. This attribute can only be applied to a method. A class can have only one method marked with this attribute. This method won’t execute if there is any exception in the method marked with TestInitialize attribute.
DataSourceAttribute: This attribute provides data-source specific information for data-driven testing.
PriortyAttribute: This attribute is used to specify the priorty of an unit test.
IgnoreAttribute: This attribute is used to ignore the unit test i.e. specific test should not run.
ExpectedExceptionAttribute: This is used in case exception is expected during execution of unit test.
Assert: This class verifies conditions in unit test.
TestContext: This class is used to store information that is provided to unit tests.
TestConfigurationSection: This class provides access to data source configuration data.
TestConfiguration: This class provides access to a TestConfigurationSection that represents the microsoft.visualstudio.testtools section in an app.config file.
The order in which methods marked with these attributes will run by the test engine is displayed below assuming we have one assembly, one class marked with TestClassAttribute, one method marked with TestMethodAttribute. I have provided this example as
Methods marked with AssemblyInitialize and AssemblyCleanUp attributes will execute only once for an assembly.
Methods marked with ClassInitialize and ClassCleanUp attributes will execute only once for each class in an assembly.
Methods marked with TestInitialize and TestCleanUp attributes will execute before and after respectively for each test method(i.e. method marked with TestMethod attribute).
I have discussed the common attributes required by the test engine to execute unit test. For more information about this assembly please read this link microsoft.visualstudio.testtools.unittesting. I’ll now move on to the next assembly i.e. Microsoft.Data.Schema.UnitTesting.
Microsoft.Data.Schema.UnitTesting:
This assembly provides the classes to run and execute unit tests. The classes grouped by namespace for this assembly are displayed below
Microsoft.Data.Schema.UnitTesting:
This namespace provides classes that you can use to create and execute database unit tests. The classes are listed below
DatabaseTestClass: This is the base calss for a database unit test. This class derives from Component. For more information about choosing between IComponent, Component, IDisposable, MarshalByValueComponent and Control while implementing a class please read my blog How to Choose Component, IComponent ….
ConnectionContext: This class encapsulated the database connection associated with the database unit test. In the DatabaseTestClass we have two properties of this type i.e. ExecutionContext and PrivilegedContext. The ExecutionContext and PrivelegedContext differ only if SQL Server authentication is used. If Windows authentication is used same credentials will be used for both. There is a reason behind having two separate contexts inside a DatabaseTestClass
ExecutionContext: This defines the context used to execute the Transact-Sql script associated with an unit test. Ideally connection string should have same credentials as that of end user. This is the ExecutionContext element in the App.config.
PrivilegedContext: This is optional and defines the context used for running the pre-test action, post-test action, TestInitialize, and TestCleanup scripts. This connection string is also used to deploy database changes and generate data. This is the PrivilegedContext element in the App.config. If unit tests run the test script only, then there is no need to specify a privileged context.
DatabaseTestAction: This class contains Transact-Sql test script and test actions.
DatabaseTestActions: This class is the design time equivalent of test and contains PostTestAction, PreTestAction and TestAction that are of type DatabaseTestAction.
DatabaseTestService: This class provides methods to Deploy database project, Execute test, Generate data and opening of Execution context and privileged execution contexts.
ExecutionResult: This is the result for and unit test and contains Dataset, execution time and rows affected.
ExpectedSqlExceptionAttribute: This attribute specifies that unit test is expecting a SQL exception and optionally specify the error number, severity, and state of the expected error.
TestScript: This class represents a generated SQL test
UnitTestingDesignService: Provides the base class for database schema providers to generate scripts for objects in their project system.
Microsoft.Data.Schema.UnitTesting.Configuration:
This namespace provides classes used to read or write configuration information to the DatabaseUnitTesting section of the app.config. The classes are listed below
ConnectionContextElement: This class represents the ExecutionContext or PrivilegedContext configuration element in the DatabaseUnitTesting section of the app.config file
DatabaseDeploymentElement: This class represents the DatabaseDeployment configuration element in the DatabaseUnitTesting section of the app.config file.
DatabaseUnitTestingSection: This class represents the DatabaseUnitTesting configuration section in the app.config file.
DatabaseGenerationElement: This class represents the DataGeneration configuration element in the DatabaseUnitTesting section of the app.config file.
Microsoft.Data.Schema.UnitTesting.Conditions:
This namespace provides classes that you can use to create and manage test conditions. The classes are listed below
TestCondition: Base class of all test conditions.
ChecksumCondition: This condition verifies the checksum of the result set in a database unit test.
DataSetTestCondition: This is the base class for test conditions that operate on a DataSet and are configured by the user during test “design time”.
EmptyResultSetCondition: For this test conditon to succeed Execution.DataSet property must be empty.
ExecutionTimeCondition: If test takes more time to execute than specified by this condition test fails.
ExpectedSchemaCondition: Specifies that result set of a database unit test must match a specific schema.
InconclusiveCondition: Represents a default condition where nothing is required or expected of a test result.
NotEmptyResultSetCondition: For this test conditon to succeed Execution.DataSet property should not be empty.
ResultSetCondition: Represents the base class for all test conditions that operate on one ResultSet.
RowCountCondition: Defines a test condition that verifies the number of rows in the ResultSet that is returned by a database unit test.
ScalarValueCondition: Verifies that a particular value in a specific row and column was expected.
This concludes the part-2 of the series “How to unit test SQL Server 2008 using Visual Studio 2010”.
In the next article I’ll show how to unit test a database using the components discussed in this article.