Thursday, May 15, 2014

Why do we need an Automation Framework?

Why should we create an automation framework?
Why all this work?
Why we just don't record our tests with Selenium IDE? This seems like an easy way to go!
Why do we have to write all this code?

There's a few reasons why recording doesn't work, but the main reason is:


Test Fragility


The major reason is Test Fragility. If we look at this simple diagram we can see that if you decided that you are just gonna record your tests and you won't gonna use some kind of a framework. Than your tests will directly depend on your application.



So what happen now, if you application changes in some way? Let say that the structure of the application changes significantly. Or even just minor little changes.

If you have a large number of tests and all those tests depend on a particular element on a page being named a certain way and that changes. All of those tests are suddenly going to break. And you will have to modify all that code in all those tests. That's really the big disadvantage of recording. Because recording is going to grab the elements by the most efficient way that it can find to grab the element instead of doing it in an abstracted way of grabbing that element. So if the element changes, as those tests break. You are copying a lot of code, when you are recording.


How can we reduce this fragility?


Now let's think about what happens, if we put an Automation Framework in place. The only modification I've made to this diagram was adding an abstraction layer. And that's what the Automation Framework is doing for you. It's primarily giving you an abstraction from the actually application.


The idea here, is that your test now depends on the Automation Framework. You are using the Automation Framework as an internal language for writing your tests. So since your tests depend on that Automation Framework. We run away from that scenario, if something changes in your application now, then you have just to update the method in your Automation Framework that manipulates that object in your application.

So let's imagine an id change, or a name of some field that you are using on an element change. Well hopefully, you've only just created one reference to it in your Automation Framework. You've abstracted the idea of how to grab that element or use that element. And so all those tests are dependent on the framework and so you've only have to change in one place. Because there's not that duplication of the dependencies on your application.

So that's the major reason why we don't want to record.



No comments:

Post a Comment