Page Object Model how much abstraction?



  • When developing a page object model, the whole intention is generally to abstract the page into methods that keeps code reusable and increase readability.

    Something I often get stuck on how high of a level do I abstract something? So for example something like a login form (or really most forms for example).

    I generally will code out something such as (This is in Cypress fwiw, but pretend it's in whatever automation framework of your choice. Code below is JavaScript):

      setEmail(value) {
        const field = cy.get('.form-control[name="username"]');
        field.clear();
        field.type(value);
    
        return this;
      }
    
      setPassword(value) {
        const field = cy.get('.form-control[name="password"]');
        field.clear();
        field.type(value);
    
        return this;
      }
    

    Generally at this point is where I wonder "Hmmm should I go ahead and wrap this forms n inputs into a larger method such as":

     login(email, password) {
        this.setEmail(email);
        this.setPassword(password);
        this.submit();
      }
    

    Which at that point I question: "Why even bother writing the independent input methods".

    So how do I decide when it's worth writing a large method that encompasses multiple other private methods...and if I write a larger "public" method should I even bother writing smaller private methods?

    I read somewhere with PoM that we should:

    Model user behaviour not user interfaces

    When I think about that statement, especially when it comes to forms it feels like one "larger" method makes sense. The only real advantage I see to splitting them up is in case I need to test negative cases (Such as not all inputs are filled out for instance). Which can technically be conditionally added to a larger form (But can also be a pain when there are multiple inputs).

    What is the best practice here?



  • I wouldn't say the PoM pattern is intended to model a behavior. Rather a user interface. Tests are intended to model behavior.

    If you have your object less abstract then you can assert the results more precisely. Having just a login method wouldn't let you assert the things which happens inside login. We'll, technically you'll be able to but asserting anything within your page class is really bad practice.

    So I would decouple behavior to a separate class.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2