Overview
In my series of posts about how to improve the quality of BizTalk solutions you deliver I will begin by discussing how we normally test schemas on BizTalk projects I've worked on.
Most people seem to simply use the validate instance function within Visual Studio as the main way to test a schema. And although this can do the job I believe the approach has the following limitations:
1. There is a known issue when validate instance sometimes thinks a message is valid when it isnt, see the following post by Yossi
2. When you test the schema from the "Validate Instance" menu option in Visual Studio this needs to be done manually and is therefore not easy to automate
My preferred approach to testing schema is to write some tests in C# and use MsTest or Nunit to run them. The tests will typically load the sample input document and then use a helper class which will run the input document against the schema to confirm if it is valid or not.
The following picture from the sample accompanying this post shows how straight forward the code for the tests are:
Aim of Schema Testing
The aim of our testing approach relating to schemas is as follows:
· We want to effectively and efficiently validate that our schema is correct against a set of sample messages
· We want to ensure that any key validation logic in the schema can be tested
· We want our tests to be automated and repeatable
· We want the tests to validate any assumptions
· We want to catch any problems as early as possible
· We want our tests to be able to be ran as part of a continuous integration process
What kind of things do we test?
In our testing of schemas we want to be pragmatic. We could provide cases which would validate the schema in every possible way but when you have a large schema this may be time consuming. By being pragmatic we aim to balance the risk of not testing every possible case versus the expense of creating and maintaining the tests. An example of this is as follows:
If a developer has developed a schema with 10 elements under the root node. If 8 of these elements can have 0 - 3 occurrences then from one perspective we could say that the developer could need to do a whole set of tests covering what happens when each of the elements has 0, 3 and >3 occurences.
This example could quickly mount up to a lot of tests which would be a pain to maintain and change when required.
For this reason we would not really test these scenarios in most cases. The types of things we would be more likely to test are:
· A known good sample message (The normal message we expect to receive) that it will validate
· Any bad message cases which have been identified in the requirements and design stages
· Things like regular expressions defined for a schema element
The Sample
In the sample (available below) I have a very simple schema within a BizTalk project. I also have a test project which contains some sample messages and a class which wraps up the logic to validate a message against its schema.
If you want to follow our approach then take a look at the XmlValidation class as this is where the XmlValidatingReader is used to validate the input message against the schema.
Hopefully that is enough information on our approach to testing schemas within BizTalk development.