XML Strategies to Improve Test Organization

Introduction

Typically, an XML data structure design is simple and to the point. It only contains business related data. In production, this is just fine because the business purpose of the transaction is clear. However, when the business purpose is testing, the nature of the test transaction is often buried deep in the XML. When you are using hundreds or thousands of test transactions, it is extremely useful to understand what the nature of the test transaction is.

This article explores ways to improve your Test Organization when dealing with large volumes of XML transactions.

Background

This article is generally targeted at Multi-Channel Communications applications. These applications include Scriptura Engage, Thunderhead, and HP Exstream. However, the concept and ideas can be used anywhere.

I identified these best practices when I had to deal with huge volumes of test transactions. Trying to search for a single transaction in a file that was several giga bytes in size was a very slow process. Using these practices, we were able to increase our efficiency and further understand when exactly I was looking at when I found it.

Using the Code

The solution is simple. All you need to do is build some testing attributes and elements into the schema, or XML document specification. These testing attributes and elements should be optional so that they are ignored by the systems that are producing the production data – unless you feel they will add value to your testing.

Here are some examples of attributes and objects that you can add to make testing cleaner.

Identify Each Transaction

<transDeck>
   <root id="123">
       …
   </root>
</transDeck>

The above transaction is tagged with an Identifier. In your application, you may want to include more attributes such as a title.

Use a Description Node

Another best practice is to create a "transaction description" element in each transaction. This node will have several properties that further describe the purpose of this particular transaction. For example:

<transDeck> 
   <root id='123'  name='test for xxx 1'>
      <transactionDescription>
          <TestTransaction>boolean</TestTransaction>
          <Name>String</Name>
          <Description>String</Description>
          <Language>string</Language>
          <LetterHead> </LetterHead>
          <State>state abbrev</State> <!--( can be enumerated ) --> 
          <SubCat id="1">string</SubCat1> <!-- (0 to infinity) -->
          <keyword id="string">string </SubCat1> <!-- (0 to infinity) -->
      </transactionDescription>
   </root>
</transDeck>

This information provides two purposes. First, it clearly identifies the transaction. Second, it provides information to the processing system about the transaction. In the above example, LetterHead, State, and TestTransaction elements were defined to help the target system understand certain aspects of the transactions. These elements should vary based on your needs.

A further explanation of these elements is as follows:

• Name – name of the test or document
• Description – an entry describing a test. This should include enough detail to differentiate this test transaction from other similar transactions.
• Language – this identifies the language form the transaction should use.
• LetterHead – not necessarily associated with testing, but identifies the letter head style that might be used in a document production system.
• State – This identifies the state associated with the transaction.
• SubCat – This helps identify the sub-category the document belongs to.
• Keyword – This will be used to point out special situations or test categories that the letter falls into. If the transaction was a targeted letter, then the keyword might identify the audience. When quantitative analysis of the test coverage was reviewed, then this indicator can help isolate test transactions that fit a specific grouping. For example, if a transaction needed a specific form to be included by the shared content, then the form name would be specified.

Both the subcat and keyword are important because it will allow custom tools, to be developed, that will select and evaluate transactions.

Remember, other elements should be added as fits your use case.

Schema Concerns (XSD)

In many systems, things that exist in an XML document are largely ignored if they are not documented by the schema. Therefore, it is usually not a problem if these elements are not defined in the XSD that defines the XML Structure. If, by chance, your target system requires the elements to be defined, then you will need to include the elements and attributes in the governing XSD.

On advantage of including them in the XSD design, is that the target system can use the elements directly to help with the testing. For example, if this is a test transaction for a document production system, it might be useful to include a cover page for each document that describes the test scenario. An alternative is a more complicated watermark that identifies the test scenario.

If you do decide to include them in your XSD, remember, these should be optional elements. That way, the source system is not necessarily required to populate them. Most of these transactions will include a lot of information that will not be attractive to a production transaction deck.

How This Can be Used with Thunderhead Now

Thunderhead Now can use these attributes in several different ways and are only limited by your
creativity. Here are a few I have implemented in the past.

Cover Pages – You can use the Scriptable Batch Config to prepend a cover page if the test transaction element is true. This gives you complete details about the test and can be included on every transaction.

Channel Job Properties – In each transaction, the channel job properties are recorded in the logs. You can use the Job Console Manager to quickly identify what channel job properties have been defined. This will help quickly identify the transactions that failed and perhaps why they failed. Channel Job Properties can be assigned in the Scriptable Batch Config or through the template properties for each channel.

Ghost Layout Regions – The layout and template can include ghost region in the header and footer that print information (“Test”, transaction information, and more) in the header or footer. This will clearly identify the transaction and other significant details. The style can be of a lighter gray to make the information a bit transparent and the best part is that it can be triggered on the test transaction element so it will be ignored in production systems.

Watermarks – Based on the information in the form element, different watermarks can be included.

History

• 18^th September, 2014 - Initial submission