Unit Testing Api Proxies

[#1]

How do i UNIT Test my proxies.what is the best approach...

[#2 · Accepted solution]

There are certainly good JS frameworks that can be leveraged for unit and functional testing. Here's an example of Forecast weather API tests leveraging Mocha framework integrated with Apigee Grunt Plugin. So, you could also leverage other frameworks by swapping it with Jasmine or QUnit in Gruntfile.js config file.

In this sample, the test inspects the response payload to assert that it contains Sunnyvale as the city and that response code is 200:

  describe('Check weather in cities', function() {
      async.each(weatherData.simpleWeatherArray() , function(cityData, callback) {
        it('you should be able to get forecast weather for ' + cityData.name + ' from this API Proxy.', function(done) {
           var options = {
                    url: cityData.url, //'https://testmyapi-test.apigee.net/weathergrunt/apigee/forecastrss?w=2502265',
                    headers: {
                      'User-Agent': 'request'
                    }
           }
            request(options, function (error, response, body) {
                expect(body).to.contain(cityData.name) //Sunnyvale, Madrid
                assert.equal(cityData.responseCode, response.statusCode)
                done()
              })
            })
        callback();
    });
  });

Please let me know if you need any directions on this.

[#3 · Accepted solution]

There are certainly good JS frameworks that can be leveraged for unit and functional testing. Here's an example of Forecast weather API tests leveraging Mocha framework integrated with Apigee Grunt Plugin. So, you could also leverage other frameworks by swapping it with Jasmine or QUnit in Gruntfile.js config file.

In this sample, the test inspects the response payload to assert that it contains Sunnyvale as the city and that response code is 200:

  describe('Check weather in cities', function() {
      async.each(weatherData.simpleWeatherArray() , function(cityData, callback) {
        it('you should be able to get forecast weather for ' + cityData.name + ' from this API Proxy.', function(done) {
           var options = {
                    url: cityData.url, //'https://testmyapi-test.apigee.net/weathergrunt/apigee/forecastrss?w=2502265',
                    headers: {
                      'User-Agent': 'request'
                    }
           }
            request(options, function (error, response, body) {
                expect(body).to.contain(cityData.name) //Sunnyvale, Madrid
                assert.equal(cityData.responseCode, response.statusCode)
                done()
              })
            })
        callback();
    });
  });

Please let me know if you need any directions on this.

[#4]

Diego is absolutely correct. We see some clients also utilizing JMeter and other such tools. While a bit heavy for unit testing, the JMX artifacts are repurposable for load testing.

My recommendation: use the tool that is best understood and integrated in your organization. Testing an API is possible with most of the major testing frameworks.

[ozanseymen · Accepted solution]

With an Apigee implementation, when we talk about unit testing we are mostly referring to "unit testing" custom code like javascript, java, python, node.js - and it is whole different debate how useful they are if your integration testing is touching most/all of the code. They are extremely useful if custom code doesn't participate fully in API responses, e.g. loggly integration code in JavaScript or any other service callout that doesn't contribute to API responses.

However it is a must-have to do proper integration testing for your API - this would test how clients are integrating with the API and in turn how API is integrating with the backend components. In order to do that you would hit the northbound API interface with some input and assert the responses from the API (as in @dzuluaga's example above).

I'd argue that unit testing frameworks are too low level for doing such API integration testing. This is the whole reason why we are working on frameworks/tools like apickli (https://github.com/apickli/apickli).

Just for comparison, here is how @dzuluaga's example above can be written using apickli/gherkin:

Scenario: Check whether in cities
GIVEN I set User-Agent header to request
WHEN I GET /weathergrunt/apigee/forecastrss?w=2502265
THEN response body should contain Sunnyvale, Madrid
AND response code should be 200

Full gherkin language supported by apickli can be found here: https://github.com/apickli/apickli#gherkin-expressions

[Oliver_Ogg]

Slight typo in that apickli URL: https://github.com/apickli/apickli 🙂

[#7]

Great discussion!

JMeter as great as it is for performance testing stores test scenarios in custom XML structure and this becomes an issue if you have more than one person writing tests and using code version control.

Cucumber is a nice little framework which is used by many teams for all sorts of testing.

As @Ozan Seymen mentioned above project we created based on Cucumber.js (JavaScript implementation of Cucumber framework) might be what you are looking for.

It supports both Gulp and Grunt task runners and can be fully automated as well.

[#8]

Agreed @Ozan Seymen and @szukauskas. It'd be great to have a sample API Proxy including instrumentation to be deployed in Apigee Edge showcasing how Apickli is used throughout the lifecycle.

On a side note, I think unit testing has a great deal of value still. Especially by providing early on feedback loops to developers, when integration tests aren't available at the start of the API program. As a good citizen, my code should be covered regardless tests aren't provided upfront. However, the definition of the unit testing for APIs needs a change in perspective by the stakeholders. One of the main principles is that unit testing should be done in isolation, so without a backend or a fake one. So, one might ask, how can this be done with APIs when they typically act as a middleware between consumer apps and the backends? There are good frameworks out there that can help you with that. I posted an article on precisely this matter How to build API Proxies with Mocks. Also, please take a look at this article leveraging Node.js PassThroughs How to unit test NodeJS HTTP requests?

[ozanseymen]

Hi @dzuluaga

For practical reasons only I am against writing unit testing for code that can be integration tested in most scenarios. What we don't want is to get locked in a situation where you change a lot of testing code (integration and unit) when some part of the code is changed.

I support the idea that integration testing is the most important testing we do but it should be supplemented with unit testing where applicable.

I've also just posted an article explaining where unit testing might be applicable for Apigee context: http://community.apigee.com/articles/3964/unit-testing-javascript-code-with-mocha-sinon-and.html

[#10]

Agreed. Maintaining tests can become a maintenance nightmare. Stakeholders should be aware of the risks of not applying TDD though. And thanks for the article, will try it soon.

[ozanseymen]

@dzuluaga - apickli is a REST API integration testing toolkit - no dependency to Apigee. It is a wrap over cucumber.js so implementation agnostic. All we need is a REST API.

We already have examples in the git repo running against httpbin.org. @szukauskas is working on additional - more high-level examples.

https://github.com/apickli/apickli/tree/master/example-project

[sureshprabhu153]

Apigee api can be tested using postman and you should enable trace in debug -->start trace and once you fire the api you can see the logs/values/policy execution in detail in trace and this way we can do unit testing.