Good day, I am quite disappointed with the debugging capabilities in UiPath.
Almost any change causes the process to restart.
Activities cannot be added without restarting the process.
The state of variables cannot be saved to later restart the debugging process at that point.
Default values cannot be assigned to complex variables, such as data tables.
The execution point cannot be moved forward or backward.
Refining and fine-tuning the robots to ensure they function correctly ends up taking too much time, in my opinion, increasing it fivefold. Are these aspects considered for future improvements?
May I ask what programming language you are used to that supports adding new code part way through a code execution? Cause in my experience what you are asking for is not supporting in programming. The code gets compiled, which means converted to machine code, once that is done you cannot really change it mid execution.
I suppose you are not understanding what I proposed, as in all the languages I know (C#, VB.NET, ASP.NET, Python, VBA), you can modify the code while debugging.
I have been doing C# for quite a long time but I didnt know you could change as much of the code during a debugging execution, so excuse me.
I think in UiPath it might be harder since the .xamls are compiled into .dlls before being ran and as such I think it might be tough to engineer such a thing.
That being said, perhaps we can talk about the issue from a different angle, are you using test cases? Cause in my experience alot of the stuff you talk about are not really much of an issue if you design small re-usable workflows and work in a test driven design mindset?
UiPath Studio at some point did introduce a feature to change the code during debugging, but the changes wonāt reflect until a new run (as the code needs to be recompiled, and thereās no effective way to save āStateā between activities since not all .NET classes (variables) are serializable). Studio will prompt you if you would like to save the changes you made during debugging.
Like @Jon_Smith mentioned, thereās very few if any programming languages that natively support the things youāre looking for. Iād suggest exploring more into how the debugging/compilation process works in UiPath Studio; this will give you an appreciation and understanding of why these sorts of features are not/cannot be supported.
Something that has helped me tremendously with the challenges I think your proposed features are trying to address is the āImmediateā window in Studio. This window only shows up after starting debugging, and lets you run non-compiled expressions during runtime with the data during that state, allowing you to āhot-debugā expressions, query data structures, and such.
Additionally, you can store default values for complex data types in other formats like JSON or CSV, and utilize activities like āRead CSVā or āDeserialize JSONā. Technically speaking, you can create default values for DataTable, its just that DataTable is a generic type and does not define its schema or data during design-time. Thatās actually a feature of the DataTable class, not a bug. If you would like to more explictly write default values for Complex types, try creating your own custom class using source files and creating a List of that type. That will allow you to define the schema in the class, and the data wherever you initialize that List.
.Net (and specifically C#) is one of them, at least for the most things on that list. IF you have the right IDE for it.
Be careful, once you get used to hot reload and moving forward/backwards freely during debug code execution, anything else will feel extremely slow and clunky. I actually write a lot of my C# code in VS first specifically because of that, then just move it to UiPath once Iām content with how it looks (also renames, namespace changes, method and class extractions etc. are way easier and safer there).
Back to the topic
The core underneath the execution is still based on Workflow Foundation xaml translations, even if itās a newer port, so I wouldnāt put my hopes up too much for most of the things listed. Effectively a lot of the code gets rewritten whole on any change, unlike āclassicā .net that can do diff compiles.
For example, execution canāt move forward and backward because the designer representation that you see is very far from the code that actually gets executed and is just ālinkedā for debugging purposes.
That said, there could be light in the tunnel for at least a part of it - UiPath already supports persistence and workflow resumptions, so theoretically doing execution snapshots isnāt that far off from that.
For default complex values, Iād suggest something similar to @eyashb but a step further - a helper class for reused test values. For example a public static DataTable GetSampleDt() on a helper class can do wonders for default initializations.
All of that aside, yeah, UiPath Studio is pretty good for an RPA IDE, but if youāre used to Rider, VS and the like, the gaps can get annoying, and it would be great if that could be looked into.
@eyashb@Jon_Smith
This is merely an example, as I have mentioned before, all the programming languages I referred to possess it. I understand that UiPath is not exactly a traditional programming language, but what I mentioned has been observed in other automation platforms such as n8n, for instance.
In n8n, this is done with a single click. When you reach a node, you click once, and all the variables are ālockedā so that you can test, modify, and rerun the node without any changes.
I have not tried it yetā¦ However, many times the changes are not related to the input data. Sometimes you notice that a message is poorly written or the title of an activity is incorrect.
The immediate window is very useful if you see the potential error before the execution line passes through the variable. However, you cannot assign all the variables every time you need them (a function like the one I described above for n8n would be helpful).
In conclusion, this is my feedback; I hope it proves to be of some use.
Yeah, no arguments on it being available more widely than I thought, your prompt motivated me to look into and I independently confirmed what you said, I just didnt know that much change was allowed. Perhaps it was my old habits that meant I never noticed how much you can do.
I think its been explained though that the XAML file isnt ran directly, its translated into .dlls that can ālookā quite different in raw code and so its quite hard to do what you ask I think.
Iād say look into test cases, its not so much about me saying it will fix your problem cause your problem is test data, but its about being able to run and re-run small workflows easily, set up complex data types as you indicated was a challenge for you and do a quick dev > test > dev cycle. The scenario of messages being bad etc can be quickly tested fixed and iterated in this approach.
