Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Creating repeatable tests for BizTalk maps is frustrating. I can't find a way to handle testing them like I'd do unit testing, because I can't find ways to break them into logical chunks. They tend to be one big monolithic unit, and any change has the potential to ripple through the map and break a lot of unit tests. Even if I could break it up, creating XML test inputs is painful and error prone.

Is there any effective way of testing these? I'd settle for recommendations for testing XSL transforms in general, but I specifically mention BizTalk maps primarily for the reason that when using the mapper, there really isn't any way to break your XSLT into templates (which I'd imagine you could use to break up your logic into testable chunks, but I've honestly never gotten that far with XSLT).

share|improve this question
    
Hmm... We have a few hundred BizTalk unit tests where I work, but I've never worked on them myself. I'll see if I can get the guy who normally writes them to post or point me to them. –  Steve Evers Feb 24 '12 at 16:22

2 Answers 2

I'm not an expert on BizTalk, but I made some unit tests for XSLT. I found several ways to do it.

  1. Creating some XML that represent the usual data.
  2. Developing a reverse tool (from XSLT output to significant XML data) and then testing XSLT over a big amount of XML (e.g. monthly invoicing, integration messaging, etc.). If you can obtain the significant part of the XML you are in the good way. This test can be presented to a customer to ensure that the XSLT was made correctly.

We use the way 1 to develop XSLT and the way 2 to test XSLT.

share|improve this answer

It depends on what you want to prove with your tests.

IF you want to prove that the transform works, you can use one or more input messages, apply the transformation, and use validation on the output message.

More specific validations can be done with XPath checks on specific fields. These kind of tests can be used to validate upto 80% of the working of the transform.

If you want to test specific corner cases (what happens when a node is not present, when this node is empty, etc..), you can create specific test messages, this will help you to reach even higher confidence in the correctness of the transform.

I think that in most cases it is not cost effective to try and test every line and every possible scenario using the transform. Therefore i would focus on the easy cases first, and specific testcases only when you see a risk, or an actual defect was discovered during testing.

Most important is to have enough real test messages as input. Try to collect as many diffrent possible input messages from the source system, and wrte test code to apply the transform on all these testcases.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.