# Testing with KDK
The KDK relies on the Mocha (opens new window) testing framework and the Chai (opens new window) assertion library.
# Modules/Plugins
Kalisio modules/plugins are Feathers modules (opens new window), so you will find most of the required information in the linked Feathers documentation.
To run the module tests including linting and coverage : $ yarn test
To speed-up things simply run the tests with: $ yarn mocha
You can run the tests of each submodule independently using the following commands for the KDK:
$yarn mocha:core # test the core module
$yarn mocha:map # test the map module
TIP
If you need to perform some specific tests, you can use the -g
or --grep
option of the mocha
command:
$yarn mocha:core -g "core:team" # run the team tests
# Web app
# API
From the root folder run the server-side tests:
$yarn test:server
This will lint and fix issues in the code according to JS standard (opens new window), then execute tests using Mocha (opens new window) and compute code coverage using Istanbul (opens new window).
From the backend api
folder you can also run the server-side tests like for modules:
# with lint/coverage
$yarn test
# without lint/coverage
$yarn mocha
# Client
From the root folder first run the web app, then the client-side tests:
$yarn test:client
This will execute tests using Mocha (opens new window)/Puppeteer (opens new window) and compute code coverage using Istanbul (opens new window).
From the root folder you can also run the client-side tests without coverage like for modules:
$yarn mocha
TIP
If you need to run some specific tests suite only, you can use the -g
or --grep
option of the mocha
command:
$yarn mocha -g "suite:groups" # run the groups tests
# Writing client tests
In addition to Mocha and Chai helpers, the KDK provides helper functions to test your UI using Puppeteer (opens new window):
test your UI components: the Runner class allows you to manage a Puppereer browser as well as the default page attached to this browser. In addition, it provides a useful inteface to override permissions, set items in local storage, catch warnings and error messages from the console, take screenshots and compare them to some reference images.
deal with your app's API: the Api class allows you to access the differents services exposed by the API.
structure your project test structure: the KDK assumes that a directory has been assigned to each test suite in order to store test data. These directories, are stored in a more general
data
directory and must be named with the test suite name. If you have any screenshot references then then they must stored in a decidacted sub directory namedscreenrefs
.
test
|_ data
| |_ suite#1
| |_ suite#2
| |_ screenrefs
| |_ suite#3
| |_ screenrefs
|_ suite1.test.js
|_ suite2.test.js
|_ suite3.test.js
When running the test data are generally generated in order to be compared to the static test data. The Runner creates a run
directory where it stores for the browser (e.g. chrome, firefox) the data for each test suite. For instance:
test
|_run
| |_ chrome
| |_ suite#1
| |_ suite#2
| |_ suite#3
TIP
The Runner clears its corresponding test suite run directory each time you run it.
# Core
# Runner
In pratice, a Runner instance has to be created in each test suite. You should declare the Runner in the before hook as well as starting. Starting the Runner creates the Puppeteer Browser and the default page. Obviously, you should stop the Runner which causes the Puppeteer Browser to be closed in the after hook.
import { core } from '@kalisio/kdk/test.client'
const suite = 'my-suite'
describe(suite, () => {
let runner
let page
before(async () => {
runner = new core.Runner(suite, { browser: { args: ['--lang=fr'] })
page = await runner.start()
})
it('my-test', async () => {
....
})
after(async () => {
await runner.stop()
})
})
# Map
TODO