Tries searching for this on the forum, but can’t find anything about it. If it’s there and i missed it, i would love a link to the post
Explanation:
When designing a new workflow, I offend find myself in a situation where I need to test 1 or more activities, to see if it works as intended. (like 1 ‘click activity’ or 1 ‘sequence’ with multiple activiteies).
Behind UIpath, I have the whole setup ready for that 1 activity, and so there is no reason for me to run the whole workflow from the beginning.
With the current version of UIPath I have no way of testing these activities without one of the following workarounds.
Copy paste the activity into another workflow (or at the “top” of the current workflow), and disable everything else.
Run the whole thing from the beginning
Feature request: Rightclick → run
I would love a feature where i could just rightclick and chose “Run this as standalone”, where UIPath would then run whatever was marked like it would have been run if it was a workflow on it’s own.
If you really want to make it fancy, then make an interface for it (maybe in the “debug” tab) , and make it so that you can create test variables, that the robot will use, when an variable have not been declared inside this test run.
…Or more in general: I would love better debugging/testing options
Considering that you may have workflow variables within the main flowchart I think it would be difficult to implement.
It makes more sense to implement Run xaml from context menu.
It will follow that you can extract as a workflow the “Stuff you want to test” and easily run it.
From a project organization perspective it makes more sense to have those in separate files.
While what you are suggesting makes a lot of sense when dealing with larger workflows, I still feel the rightclick feature would be justified for smaller workflows or single activities (Like, “Is this selector hitting the correct element”).
But I do hear what you are saying, it’ll probably be hard to implement.
I’ll keep copy pasting into my test workflow for now
What else besides testing selectors would you use this for?
Asking because for selectors, we have in the pipeline an enhanced selector editor with live validation that would solve this specific issue.
See, both of these workarounds are running parts of a workflow without context and without initialised variables, and we allow that. I think that what he’s proposing is exactly the same.
Small thing - the other proposal is not the same as its intended purpose is to run a complete xaml from project pane. Just not the one that is currently focused.
We can discuss in the other thread to not derail this one.
Testing for timing issues
When testing for timing issues between 2 (or more) activites, I need to run them all as they would run in “realtime”
When debugging large workflows
I’m not 100% sure that this is really different from 1), but when debugging a large workflow, I offend find that my solution works when testing only the 1 new activity, but when I then running the workflow again from the beginning, i still get an error.
I think this is mainly when using loops to change a variable. To test the new variable I need to loop to run.
What I currently do to solve this is copy-pasting the sequence (or loop) in question into a test workflow, setup all the variables and application in question, and run the workflow.
[edit]
I can use the above suggestion of “extracting as a stand alone workflow”, and test it from that but there’s some overheard in making the new file, and cleaning up after my testing is complete. My guess is it takes about 5-15 seconds to extract the workflow and cleanup. Where that’s not a lot of time for 1 test, it still adds up over development of a new robot.
Also if my test is running 2 activities, it’s simply faster to copy paste them into a test workflow and run that instead of extracting and cleaning up.
[/edit]
The more I talk about this the more I feel like I’m just being petty, so If you don’t feel like that’s reason enough to develop new features, I can accept that
If I find some better examples in the next few days, I’ll let you know.
What I don’t like is the idea of having large workflows which in time turn into in spaghetti workflows.
I would rather encourage the users to split them into smaller chunks instead of putting features that might be useful but would allow them to cope with that large workflow.
Now, I’m not involved anymore in workflow development so I’m waiting other hardcore RPA devs opinions.
Anil_G
rikulsilva
Yoichi
Gayathri_Ramanathan
david.rya.goderre1
Learner007
Yudhisteer_Chintaram1
Parvathy
Mr.Sanket
SAI_ESVAR_P1