# Node coverage for flows

**URL:** <https://discourse.nodered.org/t/node-coverage-for-flows/87742>\
**Category:** Feature Requests\
**Created:** [6 May 2024 09:00 UTC](https://discourse.nodered.org/t/node-coverage-for-flows/87742 "2024-05-06T09:00:21Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![lvenier](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/lvenier/32/15673_2.png) [@lvenier](https://discourse.nodered.org/u/lvenier)\
**Post date:** [6 May 2024 09:00 UTC](https://discourse.nodered.org/t/node-coverage-for-flows/87742/1 "2024-05-06T09:00:21Z")

</div>

Dear team,

I'm trying to figure out how to have a "node coverage" for my flows.  
Lest says I have a flow with 20 nodes. I am building functional tests to test/validate my flows.

I would love to know how many nodes or path are being tested with my test plan.

What is you opinion ?

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [6 May 2024 10:27 UTC](https://discourse.nodered.org/t/node-coverage-for-flows/87742/2 "2024-05-06T10:27:08Z")

</div>

One way might be to read in the flows.json file, you can then collate the nodes and compare against the nodes your tests touch. You could, of course, walk through all the nodes via Node-RED's RED object if you are doing the processing from within the same flow. But the other way means you can do it outside of Node-RED if you wanted to.

@gregorius might be a good person to wade in on this request as well since he has done a fair bit of creative work analysing flows. 😀

---

<div class="post-metadata">

**Author:** ![lvenier](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/lvenier/32/15673_2.png) [@lvenier](https://discourse.nodered.org/u/lvenier)\
**Post date:** [6 May 2024 10:45 UTC](https://discourse.nodered.org/t/node-coverage-for-flows/87742/3 "2024-05-06T10:45:12Z")

</div>

Thanks @TotallyInformation

To illustrate a bit more let's imagine I have the following flow :

 ![Screenshot from 2024-05-06 12-43-39](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/d/d/dd65610c370e6f6d21db94a7dbaea043db25ab19.png)

I would love to have somehow the following report if I have implemented one test :

![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/7/5/750554d51e7e61f7fed00c22426ca27b4edfcf91.png)

---

<div class="post-metadata">

**Author:** ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)\
**Post date:** [6 May 2024 11:00 UTC](https://discourse.nodered.org/t/node-coverage-for-flows/87742/4 "2024-05-06T11:00:28Z")

</div>

How would you assess coverage of a switch node with multiple outputs?  
A change node having multiple rules, possibly affecting multiple targets, but only one output?

It would be cute if recently traversed wires show in a different colour, but that has been discussed before and seems impossible or undesirable.

---

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [6 May 2024 11:09 UTC](https://discourse.nodered.org/t/node-coverage-for-flows/87742/5 "2024-05-06T11:09:15Z")

</div>

> [@TotallyInformation](#):
>
> @gregorius might be a good person to wade in on this request as well since he has done a fair bit of creative work analysing flows. 😀

@TotallyInformation the irony of it all - just today I created a stats button in the [introspection](https://flows.nodered.org/node/@gregoriusrippenstein/node-red-contrib-introspection) node package:

 ![Screenshot 2024-05-06 at 13.04.30](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/b/9/b9fcb7d5bec58518f54ea4c6164adf88a16fdd01.png)

(Nodes shown are mindmap nodes, further down in that list are the "classic" nodes.)

It's of course not exactly what you want but you can also check out the [code base](https://cdn.flowhub.org/?fhid=d73d76db3df96ba2&t=0#node/5262772e8a17c7f3/edit) (as a flow, function is called `collectNodeStats`) if you want to extend it.

Edit: This solution uses the Node-RED client API (i.e. stats are the browser version of the flow) not the deployed - server side - flow. The solution does not use the flows.json file.

---

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [6 May 2024 13:10 UTC](https://discourse.nodered.org/t/node-coverage-for-flows/87742/6 "2024-05-06T13:10:11Z")

</div>

Btw the [introspection](https://flows.nodered.org/node/@gregoriusrippenstein/node-red-contrib-introspection) package also has a the sink & seeker nodes that will trace all paths between two nodes. Taking your flow, that looks a little like this:

![seeksinker2](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/9/e/9e114883df821a23d7ded73eec2b84d7615e0f7e.gif)

That's probably a piece of the puzzle to work out which paths there actually are to test. The problem is the relationship between test cases and _possible_ paths in a flow.

Again that works in the client only not on the node-red server.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [6 May 2024 13:29 UTC](https://discourse.nodered.org/t/node-coverage-for-flows/87742/7 "2024-05-06T13:29:53Z")

</div>

> [@lvenier](#):
>
> To illustrate a bit more let's imagine I have the following flow

Not quite the way I thought you might be doing things. And that flow probably wouldn't ever let you test both responses - the first response change to complete would trigger the http-out, the switch should have 2 outputs, 1 for each response type. As drawn, you wouldn't need two change nodes anyway, only 1.

> [@jbudd](#):
>
> How would you assess coverage of a switch node with multiple outputs?

You would need to have something to count the number of node outputs and a way to detect which leg of the flow you went down. As the number of multi-output nodes increased in your flow, the test summary would have to get ever more complex of course and your tests would require a way to trigger a specific path through your flow.

---

<div class="post-metadata">

**Author:** ![lvenier](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/lvenier/32/15673_2.png) [@lvenier](https://discourse.nodered.org/u/lvenier)\
**Post date:** [6 May 2024 14:14 UTC](https://discourse.nodered.org/t/node-coverage-for-flows/87742/8 "2024-05-06T14:14:30Z")

</div>

For sure I would have 2 output for the switch 🙂 but I was demonstrating the objective : making sure my tests will trigger all the nodes (not all the combination of nodes. That would be an other complexity).

 ![Screenshot from 2024-05-06 16-17-52](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/1/1/111958cb46ce369b197c39bb71bb28ff7f141308.png)

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [5 July 2024 14:15 UTC](https://discourse.nodered.org/t/node-coverage-for-flows/87742/9 "2024-07-05T14:15:12Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.