Blog Post

WebAPI Testing framework

Tuesday, April 24, 2018 12:37 AM

Back ground story

I have web application that had to be extended to support new business requirements. I have decided that SOAP will not be good enough for future capability and therefore we have to move to REST and implement Web API. This will allow the application to be future proof and more versatile. Also it will allow advanced UI behavior as we can leverage JSON for data transfer and therefore reduce the size of data transfer for each request. In order to future proof the application we had also added API versioning capability.


The testing story

I can write loads of unit tests which are in code to test the end points. 

For the testing I have following requirements:

  • I want to design a framework versatile
  • It must be using business scenarios and therefore friendly for users
  • Creating new tests must be easy
  • Maintaining existing tests cannot take long time
  • I want to design my tests in nice GUI
  • The framework cannot take too long to write
  • Must be extensible 
  • I need to easily verify that contracts had not changed in any way and all endpoints with tests are always working

I could not find any frameworks and therefore I have decided to create one.

The selection

Based on my requirements I know what I need and I am pretty familiar with the .NET stack / JavaScript.

Business Requirements

Business requirements fitting to BDD and I have used it many times before for JavaScript and in .NET.

I found that there is still community around cucumber (based on Ruby) and its port into .NET as SpecFlow

The syntax is called "Gherkin" with the example as below:


Feature: Some terse yet descriptive text of what is desired
 2:   Textual description of the business value of this feature
 3:   Business rules that govern the scope of the feature
 4:   Any additional information that will make the feature easier to understand
 6:   Scenario: Some determinable business situation
 7:     Given some precondition
 8:       And some other precondition
 9:     When some action by the actor
10:       And some other action
11:       And yet another action
12:     Then some testable outcome is achieved
13:       And something else we can check happens too
15:   Scenario: A different situation

This will exactly fit my purpose of what I need to use because I can give it to any tested and from pre-existing steps they can compose any test they like, even create new ones with assistance of a developer.

Nice UI for designing my tests

I have decided on using PostMan. As my previous experience shown that using it really pleasant and especially easy to use. The fact it can be installed as an extension of Google Chrome(no longer supported) or stand alone and can be used with proxy definition has played big role in my decision.

It has couple features I liked:

  • History
  • Nice editor
  • Grouping
  • Is easy to use that everyone can use it
  • Can run tests by itself
  • Import / Export of tests

The Implementation

Once I have decided on the testing framework components I had to make it to work together. 

The glue goes as follows.

I use the name of the file as given which is used as part of the feature step definition and therefore I do not need any coding experience to get on with the tests, providing the shared steps are used.

Developer Scenario

I can get my Gherkin syntax designed by business person or tester.

The resources I need are

  • Existing postman file
  • Gherkin scenario to implement

The implementation

I will take the file, which I might want to modify. I can use JSON/XML. I will store the file following standard pattern. Use the steps defined for me and implement the ones that are not pre-existing.

Tester Scenario

I can get my Gherkin syntax designed by business person or tester.

The resources I need are

  • Existing postman file
  • Gherkin scenario to implement
  • Developer (for non standard steps)

The implementation

I will take the file and modify where necessary. I can use JSON/XML. I will create a new feature file. I need developer only when I want to create new steps within my feature file.