Mr. David Burns recently raised a pretty good question – is testing elegant? He lists a couple of examples how testing is far from elegant. The simple scenario he mentioned in relation to test automation brought my full attention – imagine a change in an element being used in many tests (could be a simple ID change, or any attribute modification for example). In such a case you may end up with a lot of failing tests and well, you should be extra careful even if any “global replace” is an option with your framework/tool.
In this post I’d like to show how testing and test automation in particular could be elegant. I use the exact same scenario David mentioned in regards to an element change. Should you keep reading you will find how WebUI Test Studio allows you to fix all your tests (the number really doesn’t matter) just by … a couple of mouse clicks. Impossible? No, just elegant.
My test project contains a couple of tests for RadCalendar for Silverlight I’ve randomly chosen. For this post’s purpose I’ve created those tests pretty random covering a couple of different scenarios.
So my tests were passing, then the calendar name had been changed and surprise – they all fail now! I’m running the first and getting immediate failure:
I double-click on the red X to find why this verification fails:
And get the following “Failure Details” dialog:
A-ha! So the test studio is searching my calendar element by XamlTag and Name. The XamlTag is correct but hey, someone has changed the name! My calendar is no longer named “calendar1” (marked in red) and the actual value is now “calendar”. That’s enough to break my tests!
I click on the “Update” button and next I choose to verify whether the new search will pass:
I get the good green “Validation succeeded” message and click the OK button to perform the update.
That looks fine, doesn’t it? However, what if I have 5 other affected tests? Or a 100 other tests to fix?
No, I don’t have to perform this again and again. As soon as I click the OK button above, a new dialog appears:
Yep, that’s correct. WebUI Test Studio lists all the tests in the project and all their test steps affected by the element change (and all of them will obviously fail as well). I check the “All” item and click “OK” to save all the updated tests.
Isn’t it elegant?
The reason why one can so easily fix all the broken tests is the way WebUI Test Studio tracks the elements in use. There is a common repository for all the elements so that each test and test step links the respective element in the repository. Should you create a new test running the same element behind the scenes you simply get another reference to the same element if already used.
One of the test studio plug-ins is called “Elements Explorer” and stays always open on my end. Here is a hint -- choose a step in your test then look at the elements explorer to see the element pointed:
You can locate that element in the tree (“Locate in DOM explorer”) or take a look at its search method by choosing “Edit Element”. It will open the same “Find Logic” dialog I showed above.
I hope this information helps and you’ll enjoy WebUI Test Studio v2.0 Beta. If you haven’t downloaded it yet you can find it available in your Telerik account. We will be happy to get your feedback!
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.