Forum Discussion
I love these two page articles that make it all sounds so simple! :smileylol:
In reality, it seldom is.
The first thing I don't like is their POM. A class per page feels like it would get VERY big, VERY quickly.
Personally, I use locators ("where" is a control) and handlers ("do stuff" to control - I have one or more functions per control. One would be ideal, but some controls are complex and require additional functions). These form the core of most of the input require for my tests. And are completely application agnostic and portable.
So you use a locator to "point" to a control in the driver data. Then tell it the control type it should find there, and what it should do with it. (Along with any required input data and expected results of course) If I had to create a new class for every page/panel? I'd be here until doomsday! My locator and handler seems to be holding up well and avoids duplication very well.
Of course, I do have other functions. For common operations, validations, some application specific, some "shortcut" ones which are there simply to make the input a little less long winded in certain cases. But the core is definitely locators and handlers. And a good, well prepared, robust object map!
If the AUT under test is relatively small, yes, this works well. But the more complicated the AUT, as Colin_McCrae mentions, the more burdensome creating and maintaining a POM becomes. I prefer my classes for my framework to not be based upon the page, but based upon the specific action I want to execute. The framework that I started sometime ago works with this structure but it's flexible enough to either be based off a POM or off something more low-level as Colin has designed.
One thing that I do agree with is that any good, agile-friendly framework should move away from the each test being it's own code routine/keyword test and having something a lot more modularized in the code structure. Break a test case down into component steps (as much break down as you want), write reusable code for each of those component steps that can be re-purposed in multiple test cases, and drive that code from some sort of external data source. This then abstracts the tests from the code. Tests are in the data, the code simply uses the data to determine how the test is run.
Now... this seems simple, but it isn't, because it requires a completely different way of looking at test automation than what is normally deemed "acceptable". Test Automation IS development in this paradigm because the majority of the test automation work is done via code, leaving the creation of the test cases themselves open to anyone, regardless of technical background. A non-tester person, given sufficient documentation, could add a test case simply by adding more rows to the data source. And, if the framework is written well enough, adding those rows could even be pretty plain-language. "Enter myUserName in textUserName on pageLogin" can be parsed out into the necessary parts to do exactly what it says.
- Colin_McCrae8 years agoCommunity Hero
Yep. My automation framework pretty much fits in with tristaanogre's final paragraph.
Once I develop all the handlers, get the name map in place (and robust) and add on any extra "stuff" that falls outwith the big two, any tester should be able to add new tests (well, test steps really ..... many steps comprise a test) to the input sheet. And it accepts as many input sheets as you want. Which can be added and removed at will. And steps within each sheet can also be switched on and off at will.
Takes a lot more setup work to abstract the code almost completely from tests. But worth it in the long run. And I would put it down more as a development task than a testing one.
Hence my job title of "Non-Functional Test Engineer". (Although automated tests do, of course, carry out functional tests, the work to actually build all this is outwith the test job remit. And I also do performance and load testing. And I'm hoping to add penetration testing, at least to some level, to my armoury at some point as well ...)
Related Content
- 4 years agoAutomation1id
- 11 years agomurugans1011
- 3 years agoMoUddin