Under review

Warewolf testing Framework - Possible Process improvement - A better / faster way to generate unit tests in future

Wynand Vermaak 3 months ago in Studio / Output updated 3 months ago 3

Hi team,

We have noticed that when we debug a Main workflow, that contains several child workflow, we are able to see the full debug for the process. However, when we click the "Create a new test" button on the Debug Output, as per snip below, the test that gets generated only populates the inputs and outputs of the Main workflow - meaning the variables, objects and or recordsets associated with the child workflows doesn't populate or pull through - 

Image 1140

The current reality of how it is working currently is that we then have to manually populate all the other variables / objects and / or recordsets for the inputs / outputs of the child workflows in order to get the test to pass, else it will fail. Some of the variables like GUIDS are also unique with each execution, and because we are unable to copy and paste from the debug output we need to manually type these out. We work with some complex and large Main workflows with a lot child workflows, which means by manually filling in these variables, objects or recordsets can easily take 35 - 45 mins to complete for one test. 

Is there a better, faster, more accurate way of generating unit tests in the future?

A discussed low hanging fruit was to allow the ability to copy inputs / outputs from the debug output.

Please share your thinking of what is possible - we can put our heads together and come up with a good - viable long term solution that can enhance the dev process (Time and accuracy).



studio workflow variables debug

Hint - the debut output where we generate the test from has all the variables, objects and / or recordsets - inputs and outputs for all the workflows including the child workflows - can all the variables, objects and / or recordsets not be populated, instead of just the inputs / outputs of the Main or targeted workflow?

Under review

Given that it’s much easier to then remove the step if you don’t want it, this sounds like a great idea. We will evaluate.

@Barney - My thinking regarding your concern is - we can always delete a populated step, if needed (we don't do this a lot to be honest - for the sake of accurate / quality tests), once everything has loaded & populated on the test editor page?