Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initial prototype of flow testing plugin #4

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

HiroyasuNishiyama
Copy link
Member

This PR is a very small prototype implementation to confirm the design direction of the flow tester.
This prototype implements the flow test configuration node and part of the flow test UI for each node.
The actions send and match are only partially implemented tentatively.

The following modifications to Node-RED are required for this plugin to work:
https://github.com/node-red-hitachi/node-red/tree/flow-test-support

[Sample Flow]

[{"id":"7fa23d74517a5fe3","type":"tab","label":"Flow 1","disabled":false,"info":""},{"id":"943944af8e27e8f3","type":"tab","label":"フロー 1","disabled":false,"info":""},{"id":"b61a827ba9dce0a2","type":"flow-test-config","name":"Test Suite 0","tests":[{"id":"T0","name":"New Test 0","suite":"b61a827ba9dce0a2","actions":{"setup":{"_global_":[{"kind":"send","value":"XYZ","target":"5448bc8e27249d0f"}]},"cleanup":{"_global_":[]},"recv":{"5448bc8e27249d0f":[]},"stub":{"5448bc8e27249d0f":[]},"send":{"5448bc8e27249d0f":[{"kind":"match","value":"XYZ.","target":"1ab07dedd80a7894"}]}}}]},{"id":"1ab07dedd80a7894","type":"inject","z":"943944af8e27e8f3","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":110,"y":120,"wires":[["5448bc8e27249d0f"]]},{"id":"da3cdd8d6de6bcdd","type":"debug","z":"943944af8e27e8f3","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":400,"y":120,"wires":[]},{"id":"5448bc8e27249d0f","type":"function","z":"943944af8e27e8f3","name":"","func":"msg.payload += \".\";\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":260,"y":180,"wires":[["da3cdd8d6de6bcdd"]]}]

Copy link
Member

@knolleary knolleary left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for making a start on this. Some initial comments here - I haven't dug into the UI bits too much, more on the overall approach.

@@ -0,0 +1,61 @@
<!--
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not add the license header. We're moving away from doing that as the consensus is having the top-level LICENSE file is sufficient.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed license from code.

checks = [];
checkSend = {};

RED.hooks.add("onSend.flow-test", (events, done) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to discuss how the runtime side is going to work. I don't believe runtime hooks are enough here - although they will play a part.

I would like to understand what you are planning here, or if this is just a place holder to show the concept.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The purpose of this runtime hook is to insert code in the middle to inspect the message.
In the initial design, the idea of using a pluggable message router was proposed.


function invokeAction(kind, opt) {
return $.ajax({
url: "/flow-tester/executeAction/"+ kind,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do not start the url with / - otherwise it will not work if the user changes httpAdminRoot.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed the /.

RED.events.on("nodes:remove", handleNodeRemove);
RED.events.on("nodes:change", handleNodeChange);

RED.events.on("nodes:dialog-open", handleNodeDialogOpen);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I mentioned in the original design discussion, we need a proper design for how plugins can contribute panes to the editor dialog. I've not seen any discussion on that.

I don't think this event mechanism is the right approach. I have something in mind and I will get that written up in the next few days.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. I think being able to hook various dialogs would be useful also in other cases.

},
onadd: () => {
const routeAuthHandler = RED.auth.needsPermission("flow-tester.write");
RED.httpAdmin.post(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to have some documentation for each of these actions to clearly define what it is meant to do - even if not yet implemented or just a placeholder.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added simple descriptions.

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Nov 15, 2021

CLA Signed

The committers are authorized under a signed CLA.

@HiroyasuNishiyama
Copy link
Member Author

I have committed the current flow-tester code.
This commit is intended to implement most of the basic functionality.
However, I think the UI, actions, and other features need to be refined.

  • UI Improvements,
  • Enhancement to actions support,
  • Runtime support including:
    • notification of node's setting panel extension,
    • global configuration node not referenced from other node
  • ...

I would appreciate it if you could comment.

@KazuhiroItoh
Copy link

I have committed a prototype version of GUI Testing.
It can be used by installing the GUI test addon in the flow testing plugin.

I have attached a sample flow to execute each action of the GUI Testing.
./node-red-contrib-flow-tester-gui-addon/examples/GUI-Test-Example.json

@knolleary
Copy link
Member

Please remove the GUI testing from this Pull-Request. I have said multiple times the GUI testing work should not be part of the core flow testing plugin.

Raise a separate pull-request with the GUI work in. By adding it to this PR you are blocking any progress being made to get the core of the flow testing framework moving forward.

@knolleary
Copy link
Member

@HiroyasuNishiyama we again have the problem that this is a huge PR which has had months of development work happen without any feedback or discussion over important details. The bigger the PR, the more time I have to find to spend understanding it. That then takes longer for me to do the review, and you continue to work on it and make it even bigger (such as the 'action extension' apis and the gui testing work).

I had hopped our regular status chats would help us do things in smaller iterations with better feedback and communication. Rather than end up with huge pieces of work that will take me days to understand properly.

The fact I have to run a hitachi fork for Node-RED to even try out the plugin makes it harder still.

So let us focus on one bit at a time.

Following the initial design discussion, we identified some requirements on the core of Node-RED. The main one was adding custom edit panes to the node dialogs. In September last year we merged node-red/node-red#3130 - and I called out Flow Testing as being the reason for doing that work. I documented it here: node-red/designs#63 - it would appear I didn't do a good enough job to make you aware of it.

I think that removes the need for the nodes:dialog-prepare and nodes:dialog-resize events.

If there are other core changes required we need a PR to be raised so they can be discussed.

@knolleary
Copy link
Member

If I have understood the implementation notes correctly, to run a test hooks are added to the message handling path. The existing flows are not stopped or modified otherwise.

If you have a flow that starts with an MQTT In node, and you want to test different messages it could send, how does that work? Does it block any "real" messages the MQTT In node wants to send? Does it stop that node or disable it?

This was one of the big open questions I had with how we would implement flow testing - how we manage the flows when we want to run a test. I had assumed we would need to stop the flows and restart them in a 'test' mode - but I wasn't sure how that would work and it doesn't look like that is the approach you have taken.

@KazuhiroItoh
Copy link

Please remove the GUI testing from this Pull-Request. I have said multiple times the GUI testing work should not be part of the core flow testing plugin.

I'm sorry. Removed GUI test from this PR.
I have created a separate PR for GUI testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants