Generic Test Scripts

Jan 21, 2010 at 5:09 PM


Has anyone tried to test common functionality across multiple BizTalk interfaces using the same test script?

I’m working on developing generic automated tests scripts based on a suite of common test cases across multiple, similar BizTalk and SSIS interfaces.  The aim is to allow this suite of test to run across multiple interfaces with no change to the test script.

There are various differences amongst these interfaces, some of which could possibly be configured so they can be included in the common test case suite.  I’m trying to work out a good level to aim in terms of considering which differences could be catered for within the common test cases.

The sort of difference I’m considering accommodating include:

  • Different file locations
  • Different file name formats
  • Different error messages

Has anyone done this sort of thing before? Either using BizUnit or some other way?

What are your views on what level of differences should be accommodated?

I would be interested to hear of your experiences.

Thank you.

Jan 21, 2010 at 5:52 PM


The only re-use that I've come across is in a previous employer/team where we had a set of common steps which we could pick up and 'compose' into a test case/. Each step was in a different xml file and all these files were in  a single folder representing the test case. We then had a custom runner which picked each file up and called BizUnit.  The runner was just a forms app which knew what these folders were all about.

Maybe you could employ something similar but in the test case themselves , instead of hardcoding folder paths etc, do a File read from a config file also available in the same path. That way you have config per test . Its possible to get more sophisticated when loading config data into  context, but you'd probably be looking into custom bizunit steps then.



Jan 22, 2010 at 9:31 AM

Hi benjy,

The custom BizUnit steps using config files was the way I was currently thinking to go about this, although I was considering only one config file per test suite. The custom steps could read the one config file to find the configurable difference as mentioned above and use them within the step. 

Your idea about composing tests using files containing a single step is interesting, I will think about the possibilities of this approach in this case.

Thank you for your response, it’s much appreciated.