Concepts of XML and XSD, Their Structure and Peculiarities

If you are a tester and you need to perform API testing, you must understand well and have an eye for 2 main data transmission forms:

1. XML – used in SOAP and REST requests;
2. JSON – used in REST requests.

So, in the article, we will try to consider in detail the first concept.

XML is a special extensible meta markup language used to save and transfer data. Hence, it is possible to see this inside the API and a program code.

Concerning SOAP, it is the only right and available format for transferring outgoing and incoming information.

Explanation of XML abbreviation

XML Structure

All the elements inside an XML document should be in special tags (some kind of a special text wrapped in angle brackets, <tag>). The text inside these angle brackets is a tag name. Commonly used paired tags consist of 2 parts: opening and closing tags.

Also, the XML file has a root element. It is a tag with which a document begins and ends.

About REST API, a document is a special request that can be sent by a system or response that it can receive.

To define a request, one should use a root element. Usually, it is referred to as <req> / <main> / <sugg>. It shows the beginning and end of a request. There is a request body inside such a root element – the request itself (parameters that a user has to transfer to the eternal system or other architecture).

All the elements data are saved between opening and closing tags. People use a line, a particular number, or nested tags for this. For example, name_attribute = «value of attribute».

XML Prolog

Sometimes, above any XML document, you can read something like this:
<?xml version=”1.0″ encoding=”UTF-8″?>.

This line is called XML prolog. This particular presents the XML version used in a document and character encoding.

It is worth noting that the prolog isn’t mandatory. So, that’s fine if it isn’t there. But if it is still there, it should be 1 line inside any XML file. UTF-8 is typical XML file encoding by default.

XML Schema

Regarding the XSD (XML schema), this is a simple description of the created XML file. It is some kind of technical requirement created on program language in XML format.

But the thing is that the testing according to the schema can be easily shifted to a machine, and a programmer doesn’t even need to write down every test (he/she just has to develop one schema whereby the testing process will be performed).

If a user creates a SOAP method, for example, the schema should include information on:

• Fields that request will contain;
• Fields of the response;
• Data types that will be reserved for each field;
• Fields that are required and optional for filling;
• If there are fields by default or not;
• If the field is limited in length;
• Additional features of the field;
• What is the structure of a request according to the type of nesting element?

And now, when a user receives any request, it should be validated according to the XSD. If the request is correct, the method is launched and the whole embedded business logic is processed.

But sometimes this logic may be time-consuming and difficult. For example, create a selection by parameters inside a large multi-level database or perform testing of 20 different tables of databases, etc.

All this means that there is no need to start an extremely difficult task if you understand from the very beginning that there will be a bad request that will be showing an error every 2 min during testing. That is validation according to the XSD allows testers and end-users to instantly filter out incorrect requests without cluttering the software.

Users and Program Requests

Moreover, similar protection can be installed to some client program to send various requests. For example, SOAP UI can test user requests with a view to well-formed xml. But it simply won’t send a request to a server if you make an error somewhere. As a result, this saves time on sending future requests.

Nevertheless, based on a simple SOAP UI, an ordinary user can understand how to make requests correctly. But who is this ordinary user?

1. A software developer who uses the necessary API: he/she just writes in a code what exactly should be sent from one system to another.
2. A tester who needs to thoroughly check this API: he/she needs to understand how a request is created and formed (with all the consequences that come with it).

Needless to say, ideally, a user should have carefully crafted technical specifications with all the details. But unfortunately, this happens rarely. As a rule, the requirements are absent at all or it is out-of-date from the technical point of view.

Now, we analyze how to use the schema when establishing SOAP UI:

• Our programmer creates some XSD (XML schema) for API request: for example, it is needed to send an X element which will have child data types. Some of them are mandatory and some are not.
• The programmer of a client system, which must integrate with our system, gets acquainted with the schema, and creates personalized requests exclusively for it.
• The client system sends all requests to us as testers.
• The system, which is monitored by testers, validates requests according to XSD only – if there is a bug, the test will definitely not pass.
• If the test passes on XSD, the business logic is checked and can be used on a multiple basis.

Well-Formed XML

All XML documents must comply with certain conditions. A request with incorrect syntax doesn’t only go to a server but also be rejected by a client. First of all, there should be testing on well-formed, and only then the rest business logic.

Basic rules of well-formed XML:

1. There is a root element;
2. Elements have closing tags;
3. All the tags are case sensitive;
4. There is a correct embedding of elements;
5. All the attributes are in quotes.

If you provide software testing services, then you will have to correctly break a request in XML format when you check it. Of course, the validated system should deal with such defects, and correctly return special error messages. But unfortunately, it happens not so often.