Can we pass the excel file as data source during runtime?
Yes, Pls explain
No, you cannot.
The excel used to create data variations is a one time import. It is transformed into a JSON file. There is no link between the Excel file after that.
You must import the data again when it is updated.
Test Queues are intended for loading data as needed in test cases.
Yes you can do that, But not at data driven.
You can Initialize Read Excel before calling your test cases and read all the data from excel and pass into test cases.
Respectfully, I disagree with this being a solution as you abandon all the advantages of a data driven test case by doing this and no longer achieved the same purpose or goal.
I do agree, But if you want to pass the dynamic data and read it from excel then there is no other way. you will have to lose Data driven testing and opt other way.
Data driven has a disadvantage that you can’t call data dynamically. If you have any data change then you need to import data and redeploy again.
Again, I disagree, I described the intended way from UiPath to load data dynamically, via Test queues.
Its not a great system in my opinion, but that should be the first thing to try.
Yea !! But test queue item will not be a data variation test cases.
I am talking about his first question. how to read data dynamically from Excel sheet. you can get disagree but the way we can achieve it using excel I am saying it.
Indeed, and the answer is no, as I indicated. What you suggest is different for the reasons I suggested. Which is why I disagree with your answer.
Answer is NO for Data Driven testing but that is not the intent here. I am just proposing an alternate solution where this can be achieved it all depends on original post owner to accept it or not.
I read the topic as clearly asking about data driven testing. What you propose elimates the ability to run individual data rows etc which is why I say its not a valid solution.
Of course up to the OP, but to me your answer does not resolve the issue in a satisfactory way and test queues is actually a way to maintain the ability to run individual lines and have each test execution be separate, and have dynamic data.
It is unfortunate you are unhappy I disagree with you, but I find your advice to be wrong or misleading and am trying to provide accurate information.
To further justify this, please read the documentation, here you will see test data queues can be used as a source for data driven testing, most accurately answering the need to have dynamic test data.
Infact, one of my main hesitancies regarding the Test Data Queues was that the data is emptied afterwards, making them a maintenance issue.
Instead I think the data service is the most appropriate compromise to this issue where you can connect your test case to the data in a data entity. It can match Excel really closely and you can edit and change the test data fairly easily. That would indeed be my strong recommendation.
Unlike the suggestion of reading the Excel in a workflow and invoking the test cases one by one this would maintain your test cases as being able to run individually and be part of a larger Test Set in the Orchestrator.