frodovdr/node-red
1
0
Fork 0
mirror of https://github.com/node-red/node-red.git synced 2023-10-10 13:36:53 +02:00
Code Issues Releases Wiki Activity

Updated Flow testing (markdown)

Kazuki Nakanishi 2018-12-14 16:38:15 +09:00
parent 2ff43e4ada
commit 1fc805d18f
1 changed files with 16 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
Flow-testing.md

@ -13,6 +13,7 @@ This design note focuses on realizing flow testing.
Basic requirements of this tool are as follows.
- Node-RED user can test flows without programming.
- Node-RED uesr can see the test results on the editor.
- Node-RED developer can test flows with CLI.
- It should test the original flow as is. If it tests a copied flow of the original one, sync problem will happen.
## Usecase
@ -21,8 +22,7 @@ Basic requirements of this tool are as follows.
# User interface
## Test node
There are two new nodes called test-in node and test-out node. Test-in node sends a mock message on behalf of the actual input node such as http-in node. Test-out node receives a message on behalf of the actual output node such as http-response node.
One test case consists of exactly one test-in node and one test-out node. One test case can cross tabs.
There are two new nodes called test-in node and test-out node. Test-in node sends a mock message on behalf of the actual input node such as http-in node. Test-out node receives a message on behalf of the actual output node such as http-response node. Test-in node and test-out node can handle multiple test cases.
![Flow testing model](https://raw.githubusercontent.com/wiki/node-red-hitachi/node-red/images/flow_testing/FlowTestingModel.png)
@ -54,6 +54,9 @@ Test-out node verifies whether the received message is exactly the expected valu
![Testing out node properties](https://raw.githubusercontent.com/wiki/node-red-hitachi/node-red/images/flow_testing/test-out_node_properties.png)
- Target
- Specifies a target node to be substituted by a test-out node.
- When you click the link on the right, all nodes except for test nodes will be shown.
- Cases
- Specifies one or more test-in nodes. In each test-in node, one or more test cases can be specified.
- Test in
@ -106,7 +109,7 @@ Option 1 is to store into flow.json. Option 2 is to create a new file test.json.
- Option 1 (flow.json)
- Easy to share flow data including test data.
- Data will get larger even if a user does not need to run a test.
- Data size will get larger since the test data contains JSON data.
- Option 2 (test.json)
- Can divide production code and test code.
- Need a function for storage API to load a new file.
@ -114,6 +117,16 @@ Option 1 is to store into flow.json. Option 2 is to create a new file test.json.
## Test driver
Needs additional discussion about which test driver should be used. If it is possible to show test results on the sidebar using Mocha, using Mocha would be good. Otherwise, we may need to implement test driver by ourselves.
## Examination
When comparing the actual data and expected data, we need to consider the following cases.
- If the property in `msg` is specified in expected object, the property will be compared.
- If the property in `msg` is not specified in expected object, the property will be ignored.
- This case always happens because `msg` object contains a random ID.
- If the property in expected object does not exist in `msg`, the test case will be failed.
## Settings
This flow testing feature should be turned on/off. Add a flag in settings.js. The default value is false (turn off).
# CLI
This flow testing needs to be run on the CLI for targeting to run automatically on Travis CI when receiving a pull request on GitHub.
When running a command like `grunt test-flow`, Node-RED runs flow testing then outputs each result such as the existing Mocha tests.