First test case based on orded type (input argument) creates an Order and returns the order number as an output argument - this order number needs to be passed to test case #2 if test cases are being run within the same Test Set.
Test case #2 gets the order number as an input argument and performs the test. As a result it returns confirmation number (another output argument) - this will be input for next test case.
Last test cases takes two input arguments - Order number from test case #1 and confirmation number from test case #2. Based on that data test can be finished.
What is the best solution to achieve that?
Is is test data queue? For example:
Test Case #1 should add “Order Number” to test data quee which could be consumed by test case #2 and so on?
What are possible options/good practices?
I believe this is a general problem for all data driven end 2 end tests.
Can you run TestCase2 and TestCase3 independently, without running TestCase1 before?
Are there any additional verifications that you need when running all 3 tests (compared with the individual verifications of each test)?
For the e2e test, as far as I know the order of the test cases execution is not guaranteed. So for now the best solution would be to create a new TestCaseE2E that will invoke the other 3 test cases and pass the parameters from one to another.
Thanks a lot for your input.
Test Case2 and TestCase 3 can be run independently as long as you provide manually input arguments. For test Case2 this would be order number of existing/open order in the system.
Solution with “one big” test case seems a little bit like a workaround.
Here is why:
Example with 3 test cases was just to visualize the topic. In fact we are talking about tens of Test Cases - all of them are dependant on each other (data driven).
Additionally, all of them can be run independently as long as you provide some input parameters.
Our approach is to limit Studio development effort only to create the test cases (let’s say 50 test cases per one SAP system). These test cases will serve as “puzzles” than can be handed over to business/operations testing teams.
These teams have subject matter expertise in the business process domain - they know which business cases are relevant for the process. They can connect mentioned test cases in hundreds of variations using Test Sets.
Developer is just producting the puzzles (Test Cases).
Business experts can use these test cases and connect them in hundreds of ways to test all variations of the process. (they can do it for example in Orchesstrator / they don’t need Studio)
This also means that the sequence is very important while executing many test cases withing one test set.
Are there any developments/improvements planned for the Test Set concept in the future? Also towards managing the data? We are currently considering UiPath Test Suite as the leading tool for the testing automation in our organization.
One of the key factors is managing the test data, ability to pass arguments from one test case to another while runnning as test set.
The biggest problem with your approach is the order (actually, the lack of a defined order) in which the test cases are executed. Your test set might even be executed on multiple robots in parallel, so the test cases executions will be mixed up.
Also, sharing data between your test cases is not easy. Test Data Queues ( Test Data Queues ) are supposed to act like a sort of a table ( multiple rows with the same structure ) with multiple “consumers” (test cases), and those “consumers” should read the rows sequentially. They don’t offer much support for communication between test cases. You could probably try to use Assets for that ( About Assets ) , but this will also be cumbersome, because the assets are shared in your Orchestrator account, so if you execute 2 test sets in the same time, they will overwrite each other’s values.
The best way for now is to use the Test Sets as a simple collection of test cases, and manage complex scenario in a test case that invokes other test cases. Not only that this will ensure the order that you want (the order of execution inside a workflow is guaranteed), but the communication will also be easy to implement (using the Invoke’s activity arguments).
Thanks for you answers.
I tried the approach with one big Test Case - however I’ve stumbled accros the issue with missing input arguments. For some reason when I invoke other test cases within one big test case the input arguments for the lower level test case are not visible in the orchestrator - is this a bug?
Hi Krzysztof!
I’m not sure I understand the issue. Can you post a picture from Orch, showing where do you expect those argumets to be displayed?
George
ashokkarale
Anil_G
ppr
SorenB
sharazkm32
k.sakaguchi0804
sven.wullum1
supermanPunch
sonaliaggarwal47
basavarajbennur07