<script type="module">
import loc from 'https://cdn.skypack.dev/3loc';
</script>
README
3loc
A simple-yet-customizable integration test tool:
Choose/write a test scenrio for your integration tests
Writes our test fixtures into one or several CSV/YAML files
Run the command and enjoy the results !
Principles
3loc runs tests against existing system, sending input and expecting results.
If received results are not the one expected, it will complain.
It's focused on Http services, SOAP and REST.
Test scenarii are basically JavaScript files, containing a serie of actions and expectations.
You will surely need to run the same scenario multiple times, with slight changes in the test data: body sent to the tested WebService, or expected status code.
We called them fixtures, and you can externalize them in a dedicated file (multiple format are supported).
In fact, the fixture file is the entry point when using 3loc, as it defined the scenario file used.
Installation
3loc is built upon Node.js 4+.
You'll need to install it on your computer to use it.
gt;&appid=<$ appId gt;&includepodid=Result'
})).
then(expectStatusCode(<$ status gt;)).
then(expectXPathToEqual('//pod[id="Result"]//plaintext', '<$ sum gt;'));
It makes an Http call to the Wolfram API, get and parse the XML content,
checks the received status code and check the result with an XPath expression.
See thoses <$ gt; placeholders (input, sum...) ? they are replaced with the provided test data.
With YAML
YAML is probably the best choice to write your fixtures.
Here is the YAML file for the above scenario:
scenario is the path the the scenario file (required).
tests is an array of objects, each considered as the specific fixtures of a given test.
If 3loc find two objects in tests, it will runs the scenario twice, using the given objects.
Inside tests and in root level, you can put anything, from simple string/boolean to complex array/map structures.
The content will be used inside the scenario file:
input, sum and status are defined at test levels
appId is common to all tests (but can be overloaded per test)
If you specify a name at test level, it will be used in final report.
Otherwise, a name with test number will be generated.
You can't use different scenarii for each test. If you whish, write different fixtures files.
Last but not least, a YAML file can include other YAML files, using the following macro:
config: !!inc/file configuration.yaml
The !!inc/file performs a synchronous read of the given path (relative to the including file) and is replaced by its content.
With CSV
Less flexible than YAML, it suits some cases where data is mearly flat, does not share a lot of data, and when you want diffent scenarii.
The CSV fixtures for the above scenario is:
Each line will execute a different test.
scenario column contains the path the the scenario file (required).
Any other column contains data used inside test.
If you put dots in the column name, the data replace will be treeish.
For example, with a column named host.url, the replacement will be request({host: '<$ host.url gt;'})
and the data is an host object containing an url property.
If you specify a name column, it will be used in final report.
Otherwise, a name with test number will be generated.
You can't share data among different tests. For that, please use a YAML fixture file.
Common considerations
Whatever the format used, the following considerations always apply:
scenario path is always relative to the fixture location (you can provide absolute path as well)
scenario can directly contains the JavaScript code (only suit really tiny scenarii)
Tests are executed serially: the program bails at first error
Test execution folder is always the folder containing the scenario file.
Data used as path (load action for example) are relative to that folder
When providing scenario content directly, the execution folder is the one containing the fixture file
Logging
By default, 3loc is not really verbose.
But it can be more chatty if you configure logging: just put a logging.properties file in the execution folder.
The file syntax is a classical INI file where the category is the logger name, and the values allows to customize its parameter: