Unit Tests Vs Integration Tests

Unit testing

A unit test tests small pieces of code or individual functions alone and isolated. A unit tests should essentially just give the function that is tested some inputs, and then check what the function outputs is correct. The idea behind Unit testing is to test each part of the program and show that the individual parts are correct. Unit test does not verify whether code works with external dependencies correctly.

Integration testing

An integration test tests how parts of the system work together. Integration tests are similar to unit tests, but there’s one big difference: while unit tests are isolated from other components, integration tests are not. The idea behind Integration testing is to combine modules in the application and test them as a group to see that they are working fine. Integration tests verifies that code works with external dependencies correctly.

---

Let’s consider this simple example. Say we have 3 functions in our program: sum, multiply, and combine.

function sum(a, b) {
  return a + b;
}

function multiply(a, b) {
 return a * b; 
}

function combine(a, b) { 
 return sum(a, b) + multiply(a, b);
}

Unit tests forsumand multiply functions would be:

it('should add numbers correctly', () => {
  expect(sum(1,2)).toBe(3);
}

it('should multiply numbers correctly', () => {
  expect(multiply(1,2)).toBe(2);
}

For combine function unit testing we need to reassign sum and multiply functions to get rid of external dependencies  – unit tests should have no dependencies on code outside the unit tested.

function sum() {
 return 1 + 2;
 }
 function multiply() {
 return 1 * 2;
 }
it('should combine functions sum and multiply correctly', () => {
  expect(combine(1,2)).toBe(5);
}

But integration test for combine function would be:

it('should combine functions sum and multiply correctly', () => {
  expect(combine(1,2)).toBe(5);
}

---

Integration testing is useful for situations where unit testing is not enough. For example if we need to ensure that two separate systems – like a database and your app – work together correctly.

Integration tests are often slower than unit tests because of the added complexity. They also might need some additional set up or configuration, such as the setting up of a test database, which makes writing and maintaining them harder than unit tests. Usually there are fewer integration tests than unit tests in a test suite, because integration tests are mainly used to test how different modules are interacting with each other as parts of an overall system.

Advertisements

Unit testing with Jest (Part 2)

Testing Asynchronous Code

A lot of code in JavaScript run asynchronously: for example every time we want to make an API call or fetch some data. There are a few ways to test these situations with Jest.

Let’s say we want to test api.login function.

import * as api.login from '../../src/auth/api.login';

describe('API Auth', () => {

  describe('login', () => {

    it('should successfully login user', async () => {
      const user ='QWERTY';
      const password ='12345';

      const response = await api.login(user, password);
      expect(response).toEqual('You have successfully logged in!');
    });
  });
});

An actual implementation of this function would go to login server and compare user’s login and password, but we don’t want a real call being made. It would be slow, and we’d need an API instance to be available for testing. Instead, we want to trick our system into thinking that a real Response object has been returned from our call to api.login, and so long as that object looks and behaves just like a real Response object would, our code can interact with it just as if it were the real deal.

This is the process of “mocking”.

To start mocking in Jest is super easy. We just declare jest.mock('../path/to/module/to/mock/here.js'), and Jest will automatically replace the real module with a mocked equivalent.

but because we don’t want to go to the network in our test, we are going to create a manual mock for our api.login.js function in the __mocks__ folder. It could look something like this:

function api.login(user, password) {
  return new Promise(function(resolve, reject) {

    if (user === 'QWERTY' && password === '12345') {
       resolve('You have successfully logged in!');
    } else {
       reject ('Wrong username or password!');
    }
}

Now let’s write a test for our async functionality.

jest.mock('../api.login');

describe('API Auth', () => {

  describe('api.login', () => {

    it('should successfully login user', async () => {
      const user ='QWERTY';
      const password ='12345';

      const response = await api.login(user, password);
      expect(response).toEqual('You have successfully logged in!');

      // we can also get rid of response const:
      // await expect(api.login(user, password)).resolves.
      // toEqual('You have successfully logged in!');
     });

    it('should not successfully login user', async () => {
       const user ='QWERTY';
       const password ='54321'; 
       const response = await api.login(user, password); 
       expect(response).toEqual('Wrong username or password!');

       // we can also get rid of response const:
      // await expect(api.login(user, password)).rejects.
      // toEqual('Wrong username or password!');
     })
 }); 
});

Aside from allowing us to fake the response, defining api.login as a Jest mock function also gives us a bunch of additional useful features from the .mock property.

By accessing the .mock property of our api.login function after it has been used, we can ensure that – for example – the arguments passed toapi.login resulted in calls with our expected arguments. The full list of mock methods we can call you can find here.

Sinon.js: testing with spies and stubs

Last week, when I was going through test suite of the project I’m working on, I stumbled into this code:

const spy = sinon.spy();

const stub = sinon.stub();

Seeing these lines was new and confusing for me, so I’ve decided to dig deep and figure out what all of this means.

Sinon

Turns out that Sinon is a JavaScript library that provides developer with 3 specific testing tools: spies, stubs and mocks (aren’t considered here).

Writing an application we’re most likely have a few dependencies: it could be sending network requests to servers or connecting to databases. But when unit testing we don’t want all those requests to go out to actual servers or databases,  so we either need to set up special testing environment or do it Sinon’s way and fake the request and response with special functions, tricking the system into thinking the request was made. In this case our testing isn’t affected by anything outside the test and can’t fail randomly.

Sinon allows us to replace these difficult and unreliable parts of  tests with something that makes testing easier.

Spies

Spies  are functions that offer information about function calls, without affecting their behavior.

We can create anonymous spies as above by calling sinon.spy with no parameters:

const spy = sinon.spy();

or more common pattern is to replace another function with a spy:

const spy = sinon.spy(myFunc);

const spy = sinon.spy(object, "method");

The function sinon.spy returns a Spy object, which can be called like a function, but also contains properties with information on any calls made to it. Here is the list of properties for a Spy object that can be accessed:

• alwaysCalledOn:ƒ ()
• alwaysCalledWith:ƒ ()
• alwaysCalledWithExactly:ƒ ()
• alwaysCalledWithMatch:ƒ ()
• alwaysCalledWithNew:ƒ ()
• alwaysReturned:ƒ ()
• alwaysThrew:ƒ ()
• args:[]
• callArg:ƒ ()
• callArgOn:ƒ ()
• callArgOnWith:ƒ ()
• callArgWith:ƒ ()
• callCount:0
• callIds:[]
• called:false
• calledAfter:ƒ calledAfter(spyFn)
• calledBefore:ƒ calledBefore(spyFn)
• calledImmediatelyAfter:ƒ calledImmediatelyAfter(spyFn)
• calledImmediatelyBefore:ƒ calledImmediatelyBefore(spyFn)
• calledOn:ƒ ()
• calledOnce:false
• calledThrice:false
• calledTwice:false
• calledWith:ƒ ()
• calledWithExactly:ƒ ()
• calledWithMatch:ƒ ()
• calledWithNew:ƒ ()
• displayName:“spy“
• errorsWithCallStack:[]
• exceptions:[]
• firstCall:null
• formatters:{c: ƒ, n: ƒ, D: ƒ, C: ƒ, t: ƒ, …}
• getCall:ƒ getCall(i)
• getCalls:ƒ ()
• id:“spy#0“
• instantiateFake:ƒ create(func, spyLength)
• invoke:ƒ invoke(func, thisValue, args)
• invokeCallback:ƒ ()
• isSinonProxy:true
• lastCall:null
• matches:ƒ (args, strict)
• matchingFakes:ƒ (args, strict)
• named:ƒ named(name)
• neverCalledWith:ƒ ()
• neverCalledWithMatch:ƒ ()
• notCalled:true
• printf:ƒ (format)
• reset:ƒ ()
• resetHistory:ƒ ()
• returnValues:[]
• returned:ƒ ()
• secondCall:null
• spyCall:ƒ ()
• thirdCall:null
• thisValues:[]
• threw:ƒ ()
• throwArg:ƒ ()
• toString:ƒ toString()
• withArgs:ƒ ()
• yield:ƒ ()
• yieldOn:ƒ ()
• yieldTo:ƒ ()
• yieldToOn:ƒ ()

For example, a spy can tell us how many times a function was called ( spy.callCount), what arguments each call had ( spy.args[0] ),  what values were returned ( spy.returnValues[0] ), what errors were thrown ( spy.exceptions[0]),
etc.

Here we assert that callback function is called once:

function myFunction(callback){
    callback();
}

describe('myFunction', function() {
  it('should call the callback function', function() {
    const callback = sinon.spy();
    myFunction(callback);
    sinon.assert(callback.calledOnce);
  });
});

Stubs

Stubs have all the functionality of spies, but instead of just spying on what a function does, a stub completely replaces it. In other words, when using a spy, the original function still runs, but when using a stub, it doesn’t.

This makes stubs perfect for faking network requests or database queries.

We can create anonymous stubsas above by calling sinon.stub with no parameters:

const stub = sinon.stub();

or we can replaces object.method with a stub function:

const stub = sinon.stub(object, "method");

The function sinon.stub returns a Stub object, which can be called like a function, but also contains properties with information on any calls made to it. Here is the list of properties for a Stub object that can be accessed:

• addBehavior:ƒ ()
• alwaysCalledOn:ƒ ()
• alwaysCalledWith:ƒ ()
• alwaysCalledWithExactly:ƒ ()
• alwaysCalledWithMatch:ƒ ()
• alwaysCalledWithNew:ƒ ()
• alwaysReturned:ƒ ()
• alwaysThrew:ƒ ()
• args:[]
• behaviors:[]
• callArg:ƒ ()
• callArgOn:ƒ ()
• callArgOnWith:ƒ ()
• callArgWith:ƒ ()
• callCount:0
• callIds:[]
• callThrough:ƒ ()
• called:false
• calledAfter:ƒ calledAfter(spyFn)
• calledBefore:ƒ calledBefore(spyFn)
• calledImmediatelyAfter:ƒ calledImmediatelyAfter(spyFn)
• calledImmediatelyBefore:ƒ calledImmediatelyBefore(spyFn)
• calledOn:ƒ ()
• calledOnce:false
• calledThrice:false
• calledTwice:false
• calledWith:ƒ ()
• calledWithExactly:ƒ ()
• calledWithMatch:ƒ ()
• calledWithNew:ƒ ()
• callsArg:ƒ ()
• callsArgAsync:ƒ ()
• callsArgOn:ƒ ()
• callsArgOnAsync:ƒ ()
• callsArgOnWith:ƒ ()
• callsArgOnWithAsync:ƒ ()
• callsArgWith:ƒ ()
• callsArgWithAsync:ƒ ()
• callsFake:ƒ ()
• create:ƒ create(stubLength)
• createBehavior:ƒ ()
• createStubInstance:ƒ (constructor)
• defaultBehavior:null
• displayName:“stub“
• errorsWithCallStack:[]
• exceptions:[]
• firstCall:null
• formatters:{c: ƒ, n: ƒ, D: ƒ, C: ƒ, t: ƒ, …}
• func:ƒ ()
• get:ƒ ()
• getCall:ƒ getCall(i)
• getCalls:ƒ ()
• id:“spy#3“
• instantiateFake:ƒ create(stubLength)
• invoke:ƒ invoke(func, thisValue, args)
• invokeCallback:ƒ ()
• isPresent:ƒ ()
• isSinonProxy:true
• lastCall:null
• matches:ƒ (args, strict)
• matchingFakes:ƒ (args, strict)
• named:ƒ named(name)
• neverCalledWith:ƒ ()
• neverCalledWithMatch:ƒ ()
• notCalled:true
• onCall:ƒ onCall(index)
• onFirstCall:ƒ onFirstCall()
• onSecondCall:ƒ onSecondCall()
• onThirdCall:ƒ onThirdCall()
• printf:ƒ (format)
• rejects:ƒ ()
• reset:ƒ ()
• resetBehavior:ƒ ()
• resetHistory:ƒ ()
• resolves:ƒ ()
• resolvesThis:ƒ ()
• returnValues:[]
• returned:ƒ ()
• returns:ƒ ()
• returnsArg:ƒ ()
• returnsThis:ƒ ()
• secondCall:null
• set:ƒ ()
• spyCall:ƒ ()
• thirdCall:null
• thisValues:[]
• threw:ƒ ()
• throwArg:ƒ ()
• throws:ƒ ()
• throwsArg:ƒ ()
• throwsException:ƒ ()
• toString:ƒ toString()
• usingPromise:ƒ ()
• value:ƒ ()
• withArgs:ƒ ()
• yield:ƒ ()
• yieldOn:ƒ ()
• yieldTo:ƒ ()
• yieldToOn:ƒ ()
• yields:ƒ ()
• yieldsAsync:ƒ ()
• yieldsOn:ƒ ()
• yieldsOnAsync:ƒ ()
• yieldsRight:ƒ ()
• yieldsRightAsync:ƒ ()
• yieldsTo:ƒ ()
• yieldsToAsync:ƒ ()
• yieldsToOn:ƒ ()
• yieldsToOnAsync:ƒ ()

Here we’re replacing Ajax method on jQuery with sinon.stub. This means the request is never sent, and we don’t need a server or anything.

it("test should fake successful ajax request", function () {
    sinon.stub(jQuery, "ajax").yieldsTo("success", [1, 2, 3]);
    jQuery.ajax({
        success: function (data) {
            assertEquals([1, 2, 3], data);
        }
    });
})

 

Unit testing with Jest (Part 1)

Before this internship I’ve never written tests for my code. I didn’t think it was necessary because if something doesn’t work in your code it either crushes and can see errors in JS console or you don’t get expected behavior or result. But in the Add-on Linter project I’m working on now having a test suite is really important:

• First of all on this project is working a group of developers and there is always a fear of breaking a code by making changes or adding new features to the code that you didn’t write or did write but forgot all it’s quirks.
• Also writing tests and thinking about all possible scenarios might pinpoint problems in a code and fix them before going into production phase.
• And last but not least with tests, you are more able to change code throughout the lifetime of an application. Tests provide a safety net, allowing you to refactor at any time without fear of breaking existing code, so you can add new methods, features or syntactic sugar.

Jest

In Add-on Linter project we use a JavaScript testing framework Jest. It comes with a test runner, assertion library and mock functions.

For a function sum:

Jest test looks something like this:

 

 

Here, we’re simply testing that 1 + 2 equals 3. Let’s walk through this syntax:

• Each test begins with Jest’s built-in test() method.
• test() always includes an string argument describing what we’re testing for. Above, we’re testing that function sum “adds 1+2 to equal 3”. Writing good, clear, descriptive explanations of what we’re testing is important.
• In the expect() line, we detail what we’re expecting to occur. This function is used every time we want to test a value.
• Jest’s expect() function is rarely used alone. We usually include it alongside something called a matcher or matcher function that asserts something about the value we’re testing. In the example above, toBe() is our matcher function. It checks that the value is strictly equal to what we expect. ie: that 1 + 2 is strictly equal to 3.
• If the value provided as an argument to expect() (1 + 2) is equal to the value provided as an argument to toBe() (3), our test passes. If not, it fails.

If the test passes we see:

In case of test failure we see:

Expanding the unit testing coverage

But even for this simple function sum there are lots of scenarios that we haven’t tested. We would like to catch cases when the function stops working in case if someone modifies it’s implementation down in the future.

So let’s expand the testing coverage by creating additional unit tests:

Here we use describe(name, fn) block that groups together several related tests in one “test suite”. We added 3 additional test cases besides the initial one, varying the inputs to the function, including a case where sum function throws an error. To test that the function throws this exact error we use .toThrowError(error) matcher.

Matchers

Jest uses “matchers” to test values in different ways. You can find a complete list of matchers here.

Most common of them these:

• .toBe(value) – checks the exact equality of  two values. In case of objects it checks if it’s the same object according to memory references.
• .toEqual(value) – checks that two objects have the same key/value pairs.
• .toBeFalsy() , .toBeTruthy()  – check to ensure that value is false/true in a boolean context.
• .toBeInstanceOf(Class) , .toHaveProperty(key, value) –  checks for an object.
• .toContain – checks if an item is in an array or whether a string is a substring of another string.
•  .toThrow(error) – checks if a function throws an error when it’s called.
• .not –  chain this matcher with any other to check the opposite.

This concludes my introduction to Jest unit testing.

 

Breaking down the issue

In the previous post I described the project and the issue I’m working on as a part of Mozilla Outreachy program. Now I would like to go through the process of solving this issue.

So the issue I’ve been assigned to close in this project formulated as Convert code-base to async-await

This is a large task and will require being broken down into smaller pieces:

• Check and update Babel transpilation steps to be async/await aware;
• Convert source code to use async/await (leaving the tests as promise based initially)
• Once the source code is converted and the existing test suite passes, modify the tests to use async/await too.

Let’s go through each step more thoroughly.

Babel

Babel is a JavaScript transpiler best known for its ability to turn the next version of JavaScript into plain old ES5 JavaScript that can run in any browser (even the old ones). It makes available all the syntactical sugar that was added to JavaScript with the new specifications, including support for async/await.

Following plagins should be included into Babel configuration:

• Syntax-async-functions – this plugin allows Babel to parse async/await syntax;
• Transform-async-to-generator – turns async functions into ES2015 generators;
• Transform-runtime – does three things: 1)  Automatically requires babel-runtime/regenerator when you use generators/async functions; 2)  Automatically requires babel-runtime/core-js and maps ES6 static methods and built-ins;          3) Removes the inline Babel helpers and uses the module babel-runtime/helpers instead.

Conversion

There are 3 main things to understand in order to convert Promises into async/await syntax:

1. The word async before a function means that a function always returns a Promise. And any function that returns a Promise it can be converted to async function like this:

2. The keyword await makes JavaScript wait until Promise settles and returns its result. So we need to replace .then calls by await.

3. If a Promise resolves normally, then await returns the result. But in case of a rejection we can catch that error using try..catch block.

Tests

Though tests have their own syntax, the rules for refactoring are the same:

Introduction to the Project and the Issue

Non-technical part

It’s been almost 2 weeks since I’ve started Mozilla internship. I’ve received new MacBook, I’ve got acquainted with the project and been given an issue to work on, I refreshed my knowledge, made a plan how to proceed and dived into it. Now about all of it in more details.

First of all, it was a pleasant surprise to receive MacBook from Mozilla to work on for the duration of this internship. I didn’t expect it, but I’m beside myself with glee that I got it, and it certainly set some kind of  ‘professional developer’ mood for me.

Going further, it was great to meet my mentor and find him really easygoing about the process of the internship, especially given our 6-hour time difference.

So, let’s talk about the project and the issue I’ve been assigned.

The project

First of all, the project I’m working on is called Addons-linter

Add-ons allow developers to extend and modify the functionality of Firefox. They are written using standard Web technologies – JavaScript, HTML, and CSS – plus some dedicated JavaScript APIs. Among other things, an add-on could:

• Change the appearance or content of particular websites
• Modify the Firefox user interface
• Add new features to Firefox

All add-ons listed on addons.mozilla.org (AMO) are required to pass a review by Mozilla’s add-on review team, and the first step in this process is automated validation using the Add-ons Validator.

The validator alerts reviewers to deprecated API usage, errors, and bad practices. Since add-ons can contain a lot of code, the alerts can help developers pinpoint the bits of code that might make your browser buggy or slow, among other problems. It also helps detect insecure add-on code. It helps keep your browsing fast and safe.

In a nutshell the way the linter works is to take an add-on package, extract the metadata from the xpi (zip) format and then process the files it finds through various content scanners.

Scanners

Each file-type has a scanner. For example: CSS files use CSSScanner; Javascript files use JavaScriptScanner. Each scanner looks at relevant files and passes each file through a parser which then hands off to a set of rules that look for specific things.

Rules

Rules get exported via a single function in a single file. A rule can have private functions it uses internally, but rule code should not depend on another rule file and each rule file should export one rule.

Each rule function is passed data from the scanner in order to carry out the specific checks for that rule it returns a list of objects which are then made into message objects and are passed to the Collector.

Collector

The Collector is an in-memory store for all validation message objects “collected” as the contents of the package are processed.

Messages

Each message has a code which is also its key. It has a message which is a short outline of what the message represents, and a description which is more detail into why that message was logged. The type of the message is set as messages are added so that if necessary the same message could be an error or a warning for example.

Output

Lastly when the processing is complete the linter will output the collected data as text or JSON.

The issue

The issue I’ve been assigned to close in this projects formulated as Convert code-base to async-await

What that means is that now the code -base of Addons-linter  is heavily Promise based. This issue is to convert all the Promise-based code to instead use  async/await syntax.

Why do we need to do that? Because Promises chains could be long and difficult-to-read blocks of code. For example:

function promiseChain () {
  const api = new Api()
  return api.function1()
    .then((value1) => {
      //do something
      return api.function2(value1)
    })
    .then((value2) => {
       //do something
      return api.function3(value2)
    })
    .then((value3) => {
      console.log(value3)
    })
}

Async/await is a new syntax that allows us to compose Promises as though they were just normal synchronous functions without callbacks. It’s a fantastic addition to the Javascript language, and can be used to simplify pretty much any existing JS application.

async function asyncAwait () {
  const api = new Api()
  const value1 = await api.function1()
  const value2 = await api.function2(value1)
  const value3 = await api.function3(value2)
  console.log(value3)
}

As you can see from the structure of Addons-linter I have a lot of files to work through and I think that after I completed this work I will be able to write async functions in my sleep 🙂

The letter of acceptance

Today I got a letter informing me, that my application to Outreachy program was approved and I was accepted into internship. This is a huge step for me and I hope a start of my career as a web-developer.

I don’t have an education in computer science field, my major is electrical engineering , but when I got really bored with my paper-wasting engineering job, where I could never see the results of my work, I decided to learn the craft of the future – web-development.

I know that a lot of web-developers are people without any specialized education, that they just learned all of it by themselves, but for me this self-educating process turned out to be harder than I expected. There are a lot of suggestions in the web about how to become a web-developer. Perhaps even to much. Because for the last 1,5 years I took different online classes, tried to learn different languages and frameworks, switched from front-end to back-end and back and ended up at the place where I’ve heard about a lot of things, done some of them, but real good at none.

So I hope that this internship with Outreachy will become the real foundation for my career and I’ll try to describe to the best of my abilities the 3 months I’ll be in this program, my learning process and everyday thoughts, my development struggles and ways of finding solutions.

Let the trip begin!