2. Using Test-Driven Development
Test-driven development is a methodology that
states developers should first think about how to test their software
before they build it. The software tests are written during the design
phase and traditionally take the form of a unit test and unit test
plans. Unit tests are the "sanity
check" tests that developers will create for their software to ensure
that all the primary features and test points specified in the unit test
plan for the feature are covered. For example, a piece of code that
adds two numbers A and B and produces the result will most likely have a
unit test plan that states that when you pass in 1 and 2 as parameters,
you should get 3 as a result. If not, something is wrong with the code.
This is probably the simplest form of a unit test. Extending this
example further, unit test plans also should cover error conditions. For
example, if your code were to display the result of the division of two
numbers, an error check should be made to ensure that the divisor is
not zero. In this case, there would be a unit test that attempts to
divide by a zero value and check to make sure that this is handled.
To facilitate the creation of unit test plans for BizTalk projects, a good tool to use is BizUnit, which is a free tool redistributed from www.gotdotnet.com. BizUnit is an add-on application for NUnit,
a community-developed tool that allows developers to create unit test
harnesses for their source code. For more information on BizUnit and
NUnit, see the release package on www.gotdotnet.com.
Once you have created the unit test plans and the
associated unit tests using BizUnit and NUnit, you need to think about
how to get your test process up and running. In traditional software
projects, the unit tests will simply reference the DLL and its methods
to be tested. Test data will be passed as arguments to each of the
functions in question and the result recorded, which will indicate
whether the unit test was successful or not.
This is not the case in a BizTalk project. What
you will need to do is create a series of test messages that will
simulate the various conditions outlined in your unit test plans. For
example, in the previous exercise, you defined the interfaces for the
fictitious integration project. If you were to create unit test plans,
you would need to create XML documents to be used to simulate real-world
messages that would be flowing through the system. These documents
would be structured so that they will cause conditions in your unit test
plans to be executed. A condition might be to check whether items that
are not in stock should be rejected. This is an example of a business
requirement being tested. An example of an error condition would be to
check that an incoming document conforms to a proper schema. If the
document does not, it should be routed to an exception mechanism. Using
test-driven development helps you to think about all the potential
scenarios that might otherwise go unnoticed. Test-driven development
also helps to avoid the "we didn't code for the scenario and it wasn't
in your requirements document" argument that often occurs with the end
customer of the software.Test-driven development often helps to find
these types of issues before coding even begins and allows the customer
to decide whether or not the issue is something they want to address.
3. Creating a BizTalk Installation Package
Significant enhancements have been added to
BizTalk 2006 to augment the deployment functionality introduced in
BizTalk 2002 and 2004. Previous versions required the creation of a SEED
package or a custom Windows Installer package using BTSInstaller. In
BizTalk 2006, this functionality has been replaced by simply exporting a
BizTalk application into a Windows Installer package that can be
imported by any other BizTalk installation. As a result of this
enhancement, SEED packages and BTSInstaller scripts are no longer
supported.
The MSI package is now created by using the
BizTalk Administration Console. Since BizTalk solutions are now
organized according to applications, the console provides the
functionality to export an MSI package based on the configuration and
artifacts that are included within the BizTalk application. Additional
files can be included as referenced assemblies, which is ideal for
packaging satellite DLL files or configuration files that are not
included as artifacts but are still required for the solution to run
properly. The MSI file is generated by first right-clicking the BizTalk
application in the BizTalk Administration Console and choosing Export
MSI to bring up the ExportWizard. The wizard will guide you through the
process of creating your export package by having you select the
resource(s), dependencies, and destination location for the MSI. During
the process, a progress status window is provided and a final summary
page appears with any failures encountered during the export process.
The MSI package that is created contains the binaries, resources,
configuration, and binding file information to import the application on
another BizTalk installation as shown in Figure 3 and Figure 4.
In order to install the application, you need to
first run the MSI package on each machine that will be hosting it. To do
this, simply click the MSI package to import all the necessary
assemblies and resources and install them into the GAC. This must be
done on each BizTalk Server node that will host the application. You
then need to import the BizTalk Server artifacts into the system by
opening the BizTalk Administration Console, right-clicking the
application, and choosing Import as shown in Figure 5.
The import process not only imports the BizTalk
Server artifacts, but also sets the port bindings and port
configurations. This only needs to be performed once per install since
these settings are deployed to the BizTalk Management DB.
