31-05-22 01:57 PM
Answered! Go to Answer.
31-05-22 02:11 PM
Hi Neeraj,
When it comes to XPath functions, the shorter XPaths are more reliable and easier to maintain. But again while creating such XPaths, one need to make sure that the attribute remains stable which totally depends on the website. In your case the 'Id' attribute seems reliable since it explains exactly what it is used to indicate. However, in my websites such attributes can be generated randomly so you might need to keep an eye on all those attributes.
When it comes to speed, the full XPaths will be more faster but it will be in terms of milliseconds as shorter XPaths need to exactly locate the element based on the functions or attributes that we provide, whereas full XPaths directly define the complete path so less search execution time is required for it. However, major issue with full XPaths is that if anything in between changes tomorrow, then your whole XPath will break. For example, in your case the XPath looks like below:
/html/body/div[1]/table/tbody/tr[2]/td/table/tbody/tr[2]/td/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td/table/tbody/tr/td/form/table/tbody/tr[1]/td[2]/input
What if tomorrow during some update to the UI, the selector changes to this:
/html/body/div[1]/table/tbody/tr[2]/td/table/tbody/tr[2]/td/table/tbody/tr/td/form/table/tbody/tr[1]/td[2]/input
So here the highlighted portion got removed and hence your XPath won't work. A better approach to tackle such an issue could have been by using some XPath function as below:/table/child::input
Here, the XPath looks for a table element such that the immediate child element of it is an input element. This makes your XPath dynamic in nature as we can always say that as long as we have a tabular structure, the input field can always be recognized.
If you have some attribute associated with the input field which can be uniquely identified nothing better than that. Then in that case your XPath can become like:input[@attribute-name = 'attribute-value']
So as a best practice what I always follow is, try to make your XPaths as short and dynamic as possible. In every case this may not be possible but in most of the cases you will definitely find some pattern to it.
------------------------------
----------------------------------
Hope it helps you out and if my solution resolves your query, then please mark it as the 'Best Answer' so that the others members in the community having similar problem statement can track the answer easily in future
Regards,
Devneet Mohanty
Intelligent Process Automation Consultant | Sr. Consultant - Automation Developer,
WonderBotz India Pvt. Ltd.
Blue Prism Community MVP | Blue Prism 7x Certified Professional
Website: https://devneet.github.io/
Email: devneetmohanty07@gmail.com
----------------------------------
------------------------------
31-05-22 02:11 PM
Hi Neeraj,
When it comes to XPath functions, the shorter XPaths are more reliable and easier to maintain. But again while creating such XPaths, one need to make sure that the attribute remains stable which totally depends on the website. In your case the 'Id' attribute seems reliable since it explains exactly what it is used to indicate. However, in my websites such attributes can be generated randomly so you might need to keep an eye on all those attributes.
When it comes to speed, the full XPaths will be more faster but it will be in terms of milliseconds as shorter XPaths need to exactly locate the element based on the functions or attributes that we provide, whereas full XPaths directly define the complete path so less search execution time is required for it. However, major issue with full XPaths is that if anything in between changes tomorrow, then your whole XPath will break. For example, in your case the XPath looks like below:
/html/body/div[1]/table/tbody/tr[2]/td/table/tbody/tr[2]/td/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td/table/tbody/tr/td/form/table/tbody/tr[1]/td[2]/input
What if tomorrow during some update to the UI, the selector changes to this:
/html/body/div[1]/table/tbody/tr[2]/td/table/tbody/tr[2]/td/table/tbody/tr/td/form/table/tbody/tr[1]/td[2]/input
So here the highlighted portion got removed and hence your XPath won't work. A better approach to tackle such an issue could have been by using some XPath function as below:/table/child::input
Here, the XPath looks for a table element such that the immediate child element of it is an input element. This makes your XPath dynamic in nature as we can always say that as long as we have a tabular structure, the input field can always be recognized.
If you have some attribute associated with the input field which can be uniquely identified nothing better than that. Then in that case your XPath can become like:input[@attribute-name = 'attribute-value']
So as a best practice what I always follow is, try to make your XPaths as short and dynamic as possible. In every case this may not be possible but in most of the cases you will definitely find some pattern to it.
------------------------------
----------------------------------
Hope it helps you out and if my solution resolves your query, then please mark it as the 'Best Answer' so that the others members in the community having similar problem statement can track the answer easily in future
Regards,
Devneet Mohanty
Intelligent Process Automation Consultant | Sr. Consultant - Automation Developer,
WonderBotz India Pvt. Ltd.
Blue Prism Community MVP | Blue Prism 7x Certified Professional
Website: https://devneet.github.io/
Email: devneetmohanty07@gmail.com
----------------------------------
------------------------------
01-06-22 07:01 AM