SoapUI – WADL and Test Coverage

The most important part after developing your API is to provide a good documentation about this.

For Restful services, it is always good to provide a WADL document describing your API.

This provides a machine readable specification that can drive a human readable view as well as various testing tools. There are several other purposes of WADL.

  • DevOps can more quickly diagnose and correct problems when parts of the larger system can be tested in isolation.
  • When working in a large team base, developers who is gonna consume your exposed API’s should not approach the developers who did it for knowing more about your API functionality.
  • Developers/QA Engineers will be able to use the SoapUI project as an example of how to access the API.
  • For integrating our APIs with API Developer Portal or any other centralized ESB.
  • To derive the test coverage for our API tests.
  • You can do a rest code generation using WADL2Java in SoapUI.

Different documentations for your Web API:

There are different documentations available for your web API’s like

Even Ready API Pro version has the ability to import/create tests for rest services from the above documentations or framework with the help of external plugins.

So most of the services that I am working on are restful and I recommend WADL more as a standard. It’s always your developer’s responsibility to provide a proper documentation for your web API. But sometimes it may not happen. So in that case let’s see how you can generate WADL on your own.

How to Generate a WADL:

There are several ways that you can use to generate the WADL for your API’s and each has its own Pros and Cons.

WADL File Generator in .NET

As I am working only on .net projects, this solution will use the  leeksnet.AspNet.WebApi.Wadl package to generate the WADL. After installing this package along with its dependencies in your API project, we can be able to see the generated WADL on the root of your Web API.

http://<API-EndPoint>/help/wadl

For more details, Please refer this Wiki. WADL File Generator in .NET

Pros:

  • It is automated. No manual efforts involved.
  • We can able to see the updated description for the API’s, whenever there is a change in the API code base.

Cons:

  • Dependency on product development team.
  • Dev team may have to upgrade their MVC versions to make this solution to work.

Ready API/SoapUI Rest Discovery:

Soap-UI Pro/Ready API has an inbuilt feature called “Rest Discovery” which will help us to discover the API’s and their descriptions.

Smart Bear has lot of documentation available to guide you step by step about this feature. Have a look at here for Getting Started with Ready API Rest Discovery.

Pros:

  • No dependency on Dev team. Anyone can go ahead and generate the descriptions for their WADL.

Cons:

  • Significant risk of missed API resources – anything not exercised is not recorded in the WADL.
  • Someone from the team should own the responsibility for updating the generated WADL every time, whenever there is a change.
  • Certainly result in a fairly massive performance bottleneck, since all API traffic would be routed to a Soap-UI recorder that is not optimized for performance.

Manually Generating a WADL:

Final option is to write a WADL file manually for your API’s. If you have a good understanding about your API’s internal skeleton like resource, representation, request and response, you can write your own WADL file using any text editor.

Pros:

  • No dependency on Dev team. Anyone can go ahead and generate the descriptions for their WADL.
  • Requires no special tools.

Cons:

  • It involves lot of manual efforts and time consuming.
  • Someone from the team should own the responsibility for updating the generated WADL every time, whenever there is a change.
  • Need to know more about WADL standards and schema.
  • Possible chances for errors which may break the WADL schema.

Ready API/SoapUI Schema Inference:

When creating a REST Service without a WADL, it is often useful to be able to generate these documents anyway, so that validation is made possible, and code/documentation generation tools can be used. Ready! API provides automatic inference of WADL from the model you create in SoapUI, and also inference of XSD schemas from any incoming responses that can be converted to XML, such as XML, JSON and HTML. For more information Please refer Using Inferred Schemas.

Pros:

  • No dependency on Dev team. Anyone can go ahead and generate the descriptions for their WADL.

Cons:

  • Need to know the list of available API’s before inferred with the WADL schema.

I strongly believe that there may be still lot of available solutions to provide a proper documentation for your API. There should be some kind of automated mechanism available for Web API’s in every language like Java, Python etc.

Test Coverage in SoapUI/Ready API:

Test Coverage in the sense, I am referring to the built-in “Contract Coverage” feature in Ready API.

This feature helps us to make sure that we are writing good amount of tests for all the available resources, representations, request and response in an exposed API.

This built-in “Contract Coverage” feature in Ready API is entirely different from the term “Code Coverage” which can be achievable through external tools like Ncover, Cobertura etc.

This Coverage is possible only if we have the proper documentation/WADL provided for the API’s from product teams.

To derive coverage for your API tests, please have a look at this –  Getting started with API Test Coverage

Generate Test Suites using WADL:

If we have the WADL file available at the root of the API URL, our life is going to be much easier by simply importing it into Ready API and auto generating test suites and test cases for all the available resources in your API.

Please have a look at this to learn – How to import WADL into Ready API and auto generate API tests

Additional Note:

If you are APIs are restful, you have a choice to use either “HTTP Request” or “Rest Request” in Ready API. But I recommend using only “Rest Request”.

Please have a look at here – Getting started with Restful Requests

Also for getting API Contract Coverage in Ready API, it is mandatory to use “Rest Request”.

If you have used “HTTP Request” you won’t be able to derive Contract Coverage for your API tests.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s