I hope I haven’t confused anyone mentioning the weak points of test automation in my previous post. The gained experience however indicates the importance of looking into test automation based on straight-forward and easily maintained solutions. That’s a problem people have been trying to solve for more then a decade now. In the current post I’d like to get your attention to a key of successful test automation via using the tools extensibility.
Nowadays there are plenty of test automation solutions especially for the well-known platforms like ASP.NET Web. Should you consider automate your testing activities, you will probably find a lot of tools matching your basic requirements. Are they ready to meet the challenge of reliable test automation, though?
Now I realize my view of the automation tools has changed a lot throughout the years.
- A couple of years ago I would most probably rely on the user-friendly UI to exclaim “this is my tool”. The easier I get my first tests running and summarizing the results in human readable format, the better this tool seems to do the job for me.
- A year back, I’d first spend a few hours or even a whole day getting feedback (both positive and negative) before I shortened my list to just a couple of candidates.
- Today, one of the first features I look for is the extensibility of the tool. Then I proceed with the rest.
What do I exactly mean by “extensibility”?
No matter what kind of solution that is, the tool gives you a set of commands/routines/methods available for common use. In other words, you are supposed to build your suite of automated tests on top of the built-in commands. It doesn’t depend on how specific the tool is – think of it like a kind of API.
So is it possible the API of the tool to be extended? Can you add your own set of commands and if so, how easy can you integrate the custom stuff along with the existing list? Key questions concerning the extensibility of the tool you’re going to work with you should get answered.
Do I really need to extend the tool?
I’ve seen many good automation solutions whose functional API looks complete. Also the contributors continuously extend the built-in commands to get a solution that seems to cover the needs of the users. It is worth working on extending the provided functionality to
get easier test creation and maintainability.
For example, the built-in API may allow achieving a specific result, but the task might be hard to be fulfilled. So instead of getting the result through a code, being nightmare if updated, I encourage you to consider the implementation of a custom command that will make it easier.
A similar example: imagine a number of test cases that require close or even the exact same set of commands. Instead of repeating the steps again and again it would be great if the code can be plugged into a custom command. That will definitely help in test cases creation as well as in making the maintenance routine. Sounds familiar to the developers too, doesn’t it? Call it code reuse.
Test automation of RadControls
Although it is applicable for all the Telerik components, let me focus on some of the most complex custom controls in building ASP.NET Web applications – RadControls for ASP.NET AJAX.
Many customers request a recommended test automation solution that best operates with our components. However, talking about complex controls like these, there is no tool that can easily do the magic, unless it is especially designed for the purpose. That’s why I suggest looking for automation solutions that allow extending. The RadControls for ASP.NET AJAX sometimes behave quite tricky, so automating a lot of test cases is too exhaustive without the help of custom extensions.
My next post will be dedicated to an example of custom extensions over a popular Web automation tool. Meanwhile should you have any questions or want to share your experience on the topic, I’ll be happy to see your comments.