Example for Select with mock response

The test case name is the filename (without .ql) i.e test case name for this example will be "select-test" and the related mock files and custom asserts will need to begin with this name plus their own convention.

A point to note, though the example above uses a hardcoded endpoint, it is a good idea to get it from config (ref to ql.io doc). This way mocked endpoints can be abstracted out.

testcase-name.js tells ql-unit that user wants to do custom asserts on the response returned by the script being tested. To implement custom asserts the user will need to export function(test,err,result).

For PUT and POST requests user needs to specify a request file with a name that follows the convention testcase-name.request.requestType.requestSubType.

File name: ping-pong-post.request.application.json

{
"itemId": "abcd",
"userId": "xyz"
}

Besides the csv file containing routes and request files, user can also create mock responses and custom asserts as shown the previous example.

Example for "setup" and "tearDown" testing

Some tests requires doing some setup and appropriate teardown. This can be achieved by creating .js file like the one created for customer assert (following that naming convention) in the first example and defining "setup" and "tearDown" functions in it. Following is an example where "setup" and "tearDown" is used to create simple echo server.

Example for passing custom "engine" and/or "console"

In the Overview section user options are passed to ql-unit's .init() which it internally uses to create ql.io-engine and ql.io-console instances. Sometimes users would want to provide their own engine and console instance (e.g. for tests inside ql.io-engine and ql.io-console packages). Here are some example for that.