My Integration Testing Checklist (JavaScript)

The following is a list of tools I use for Integration Testing:

• Mocha as test runner on the back-end; while I've used Karma on the front-end with Angular
• ChaiJS as assertion library; Jasmine is also a wonderful solution that I've used on the front-end
• SinonJS for spying, stubbing and mocking classes, objects and functions
• Moxios for mocking API requests done using Axios
• Proxyquire for stubbing dependencies
• FakerJS for generating random fake data

Checklist:

• [ ] Require modules
• [ ] Main describe block
• [ ] Top level before and After block
• [ ] Describe block for every (public) function for the file
• [ ] It statement for the main flow for most code coverage
• [ ] Write expect or assert based on the function return value (test should fail at first)
• [ ] Write minimum code to make test succeed (with most coverage flow if not difficult)
• [ ] Stub dependent functions in the same file or another file to unit test this function
• [ ] Pass enough test for 75% to 80% code coverage

Notes

To keep the testing files short and simple, I usually write a separate file for a service or api file. For example, login.service.ts has a file in the test folder with a similar name.

I then add a main describe block for naming the file testing suite e.g. Login Testing Suite or Login Integration / Unit Suite. If the file to test is too long, I usually try dividing the tests into several files as the codes will otherwise become too long to follow.

Below the main describe, I write the global variables to be used in this file e.g. sandbox = sinon.createSandbox() that enables me to refer to sandbox anywhere to stub or mock functions.

Personal Tip:

If I am writing tests for a legacy system, I first write the test codes in a simple and straight forward manner just to make it pass. Once done, I shall then arrange variables for reuse if needs be, for instance, sending sandbox.stub(file, 'functionName').returns(true) to a statement above so that I can use it in the next test.

For a TDD approach, before even writing the file or function, based on the specification, I write a one liner test for the expected result - for example - getAccessToken function returns a string. At this point, the test will fail. I will then write the minimum test to make it past, that is, create the file and the function returning a string value.

This process makes software development more productive and relaxing as most of the time I only need to focus on one thing - the code coverage for a particular file.

I basically stub out all of the other cognitive efforts for an authentication system such as waiting for the compilation from Webpack, loading the login page, entering credentials and test the result manually.