The broken concept of a Page object, or Why Developers Should Be Responsible For Test Automation

Preface: I am in the middle of writing a series of posts about test automation frameworks architecture. I am still going to continue that series, even though this posts kind of devaluate the whole test automation framework concept a bit. Sorry for that, just can't stop ranting.

Looking through the internet I spotted a couple of posts where some test automation specialists were talking about "page object" "pattern"/"model", as it was something special they had invented.
Well, I also have something to say about "page object".

“Java test automation engineers were told that there are different patterns than a PageObject”
Grigoriy Myasoyedov.
1897
Oil on canvas
(collaboration from A)
“Java test automation engineers were told that there are different patterns than a PageObject” (http://classicprogrammerpaintings.com/post/153817288474/java-test-automation-engineers-were-told-that)


"Page object" may be described as a pattern that allows us to decouple things you can do with the web page (external interface describing test/business logic) from the real implementation code you will have to use to actually get things done with this bloody web page. If one heard about GoF patterns, she may think about "page object" as "page adapter" or "page facade". This does not sound too test automation specific, which is maybe a reason why "test automation specialist" tend to prefer cool "page object" term.

That leads me to the other rather shameful thought about "page object". I think, one of the most important reasons for the existence of the concept in the first place is to hide the untestable nature of the application from the test code. On pretty every blog post about page object you read that you need page object, so when UI hooks get changed yet another time you won't have to update every bloody test case, just lovely "page object".

Which may sound like a reasonable idea, and even work some times. However, I have two questions for you:
  • Does it fix the real problem (untestable and unstable UI), or just mitigates the symptoms?
  • What is the reason to touch the same UI in 200 of tests? Does not it look like, you know, test duplication?
My answer for the first question would be that "page object" does not fix the problem. It makes it actually worse. It seems that "page object" allows developers to break the UI even when functionality and appearance didn't change at all. Then, "test automation specialists", (instead of kicking that bastard's ass) will just "fix page object". I have seen an example of this just yesterday, and I am sure that was wrong.

The second question is more complicated. But, seriously, if you have access to application code, you will always prefer to limit UI tests to the extent that you just can't have more then a ~5 tests touching same UI.

From the implementation perspective, if things are done right, it usually does not make much sense to do any complex testing (like data combinations, negative cases, different Unicode symbols and other crap) from the UI level (you can test it in some other place). So why would you write more than 3-5 tests for the same UI?

That is one of the reasons why I think developers (not some "dedicated test automation" specialists) should be responsible for writing test automation for the application they develop. It is much more efficient.

I do believe, that when developers feels the pain of writing and maintaining UI tests they would pay more attention to other test types and specific test hooks, ultimately achieving effective test automation.

Also, I hope that developers would probably rather prefer making application UI more stable and testable rather than using "Test Automation Frameworks" with "Layers" and "Page Objects" to mitigate the mess they have created.

And I hope we still friends.

AQAguy.

Comments

  1. The page object pattern tracks the application state during test execution. Each page object function returns a page object, representing the application state after each action on the page. Only in extremely simple applications, or in an ideal world, would they not be needed.

    ReplyDelete
    Replies
    1. Hello Brian,

      Could you please elaborate what you mean by "tracks the application state" and how it correlates with application simplicity or complexity?

      In case of overcomplicated UI and untestable architecture we indeed may need a page object to test the mess. What I am thinking though, is that is not a cure, but pain-killer.
      If we address testability we should be able to test 95% of business logic not ever touching UI, leaving only with 5% of UI specific code, which we may test with simple tests using Selenide for example (http://selenide.org/).

      We also may choose not to automate this part at all, if we fill that ROI is negative (which more that possible).

      Test automation is not always about catching each and every issue, it is often about efficiency of QA efforts (by QA I mean the process, not team).

      Delete

Post a Comment

Popular posts from this blog

Test automation framework architecture. Part 2.1 - Layered architecture example

Test automation framework architecture. Part 2 - Layered architecture

Efficient test automation - Secret #1 | Test Club