API Testing with Frisby and Mocha

How to boost your automation skills with
a cup of energising Mocha
Lyudmila Anisimova
Olga Biletska

Why do we value software quality?
If we can’t control the quality of
applications we can’t control the quality
of our lives

Have you heard about Centerlink fault?
Centrelink - government company that helps families and
people with low income
November 2016 - New automatic debt collection system was
introduced with 169 000 letters
Complaints rate - only 276 complaints from those 169,000
letters (Jan 9)
4 billions will be raised
What’s wrong?

What is API?
API - a set of functions and procedures that allow the creation of
applications which access the features or data of an operating system,
application, or other service.

Why do we need to start with API Automation?
● Manual testing takes far longer for automated solutions
● UI Automation is usually less stable
● Maintenance of UI tests takes a significant amount of time
● Test Early and Test Often - APIs usually are implemented first

Why automation is a quick win?
This is what we get after hard work is done

What are drawbacks of API implemented?
1. Automation can bring us false sense of security
2.Automation requires everyday support
3.Automation can delay releases

Olga Biletska
Test analyst at Digital Turbine
My first experience with automated API testing

Our project: Case 1 Testing APIs manually

---------->
Fears of manual tester

Frustration ----------> Hope Frisby!
How to start?
Learn this:
● How does http protocol work?
● What is API?
● What is JSON?
● Basic commands in Javascript
● How to install testing frameworks?

What Frisby does well:
•Send request/Adding headers to request
•Check types and values of responses
•Authorization via tokens and cookies
•Allows custom methods
Frisby – RESTful API testing framework

Structure of Frisby
test case
Example: testing API calls
to subscribe/unsubscribe
user
•Spec ending
•Test description
•Request/Response
•Defining expectations
•Toss Frisby
General workflow:
● Identify user
● Get access token
● Subscribe call
● Unsubscribe call

Structure of our test case: Part 1 – identify user and get access token
Define variables: var
Define new test: Frisby create()
Perform http GET request: get()
Check response code: expectStatus()

Structure of our test case: Part 2 – verify response data
Verify responses:
Check type of response:
expectJSONtypes
Check exact values:
afterJSON(function (body) {})
Matchers:
Expect.toEqual
Expect.toMatch
What we see in the console ------->

Structure of our test case: Part 3 – subscribe and unsubscribe user
Nested test
Define variables:
Var
Define new test:
Frisby.create()
Print results to console:
inspectJSON()
Fire the request:
toss()

Frisby installation
● Install Node.js: https://nodejs.org/en/download/ (NPM - Node Package
Manager will be installed automatically)
● Install Frisby locally: npm install frisby
● Install Jasmine node globally: npm install -g jasmine-node
Useful links
Frisby http://frisbyjs.com/docs/api/, https://github.com/verdverm/frisby,
http://testerzero.com/up-and-running-with-frisby-js-for-api-checks/
Jasmine: https://github.com/JamieMason/Jasmine-Matchers
Java Script: https://watchandcode.com/courses/enrolled/60264

Case 2
Device Caps - this system is responsible for mapping Game/Application
renditions to specified devices from Game Suppliers. It also contains the
logic to find known compatibility and extend coverage on this basis.
Search system module that works based on device caps functionality as the
user should be able to find only content that is supported.

Challenges
Over 2000 mobile devices
At least 5 main browsers
At least 15 different
Android OSes to test
Time limitation of 2 weeks

Boundary analysis gives unstable results

Now this is the time for a change
New automation framework
should support long delays

Installation
npm install mocha
npm install chai
npm install should
npm install joi
npm install mochawesome

Code structure
Declare variables
“ Describe “

Code structure
“ It “
.post/.get
.set
.send
.end .end
Verify your API
response status, type
and other data
Part II

Response verification with chai and should
res.should.have.status(200);
res.should.be.json;
res.body.should.be.a('array');
res.body.should.have.length(5);
res.body.should.be.a('object');
res.body.should.have.property('id');
res.body.id.should.be.a('number');
res.body.name.should.equal('3JHGFJHJHKJHK2211');

Traditional TDD interfaces in Mocha
suite - similar to describe
test - similar to it
setup - similar to before
teardown - similar to after
suiteSetup - similar to beforeEach
suiteTeardown - similar to afterEach

API Testing with Frisby and Mocha

Links
https://mochajs.org/
http://shouldjs.github.io/#assertion-any
https://github.com/shouldjs/should.js
http://chaijs.com/

Connect with us
https://www.linkedin.com/in/lanissimova/
https://www.linkedin.com/in/olga-biletska-0aa4518a/

API Testing with Frisby and Mocha

Related slideshows

More Related Content

API Testing with Frisby and Mocha