Hi,                                            

I’m Ari and work as project manager at Frends. I’ve been working with integration projects for almost nine years in testing, development, design and management jobs. Most of those nine years, I’ve been working at Frends.
Currently, I spend a big part of my working hours with these integration guys so you might say I’m sort of an integration architect wannabe, and that’s why I also dare to say a few words about integration testing  -just few more or less trivial things that I have discovered to be useful in preventing problems later in the project.

Integration development projects and more “traditional” software development projects share many same features as far as the testing is considered. In both cases testing accumulates, starting on most atomic level and ending up on the level where you test all the components and possibly external systems as one functional entity.
However, there are also differences. I thought to bring forth few points that I have discovered good to take into account during integration development and testing.

First in the testing lifecycle there are unit tests. Actually integration projects quite rarely allow you to drill down to the level where unit tests generally rule, which, in object-oriented development, is on class and method level. Nevertheless, integration projects also try to test developed functionality as soon as there is something to test.
Since data transfer is something that is thoroughly tested during system tests, quite often natural way to start the integration development is to start by developing the transformations; therefore transformations are also natural way to start the (integration) unit tests.

Integration is basically transferring information between systems and applications, using transformations in between to fit together otherwise incompatible message formats and structures that systems expose. In order for you to be able carry out any kind testing, or development for that matter, customer and system vendors should provide example messages which can be used as an input for translator running the transformations under development. If just possible, try to avoid creating those examples yourself.

When example messages are generated it is wise to pay attention to how they are created. The best alternative is to create message directly from the production systems. Unfortunately there are several reasons why this cannot always be done, e.g. data protection reasons being one. If examples cannot be produced directly from the source systems, those have to be created manually. There are several hazards in this, like

1. Even if the structure of the example message conforms to specifications (like XML schema), the content of individual fields may differ from what source system normally produces and what is expected by the destination system.
2. Manually created examples may use different character encoding than source system normally uses. In this case, you end up having problems at least when special characters are encountered.

During unit testing you rarely have any other option to evaluate the transformation outputs than compare them against the specifications and artifacts (such as XML schemas). Also, if possible to involve customer already at this stage, business user’s sophisticated eye may reveal defects far more efficiently that any XML validators or such – especially content-related defects. Of course, the best alternative would be if the customer would have means to input the transformation results to real destination systems and see what the reaction in there is. In the latter case, however, customer needs a separate testing environment, or some way to pick out test messages from the production system if testing system is not available.

That’s it for now. If our architects still allow me to add post to this blog in the future, I could write few words about integration systems testing.