Selenium - Design considerations for filling out forms



  • I am using Selenium to develop automated test cases, some of which involve filling out forms with dozens of input fields. At the moment, I am following the Page Object Model/Page Factory design pattern, meaning that my page classes involve declaring all of the necessary elements using the @FindBy annotation and include methods for interacting with each of these elements.

    However, after actually writing the page classes for some of these tests, I am wondering if it might be more efficient for me to use an Excel file to store locator information instead.

    i.e. Instead of creating a page class where I declare 20 WebElements and write 20 methods for interacting with these elements, I use an Excel file containing the locator information for these elements, and write one for loop iterating across all the columns to locate an element and apply an action to it. What are the pros and cons of using this kind of method instead? I asked a question earlier about performance discrepancies between the two, but now am wondering about the amount of code that actually needs to be written, readability, etc.



  • I use an extremely similar design idea, however, I'm using the node.js selenium-webdriver library, and I store the page object data in JSON files.

    So some of this may be less applicable to your case, however, I can speak with accuracy to the general concept and how it's worked for my team.

    Pros:

    • Adding new, similar elements is easy
    • May open maintenance to less technical members of the team
    • If you do not frequently add new types of UI elements, ongoing maintenance is very limited, and code is very easily shared.

    Cons:

    • Adding new types of elements requires a lot more glue to support new ideas about selection and interaction
    • If you end up hacking a solution for a one-off case, you suffer a dramatic impact to test readability
    • You will likely eventually discover some weird edge case that forces you to re-think how you structured your code and/or your page object schema altogether, and that will probably catch you by surprise.
    • The complex bits of your code become centralized in a handful of locations. This is sometimes a pro, and sometimes not, but it hurts pretty bad when it bites you.

    I would recommend this method strongly if:

    • You have an old project with a well defined product
    • You have less technical testers interested in helping out with browser automation tests
    • You have an application that very rarely introduces new UI concepts.
    • The overwhelming majority of your features are new variations on things your app has done before, this method works quite well.

    This could be a bad idea if:

    • You have a newer project
    • You have a project that focuses strongly on a wide variety of element interactions
    • You frequently break ground on newer, more complicated UI features
    • Your product is less clearly defined

    As an aside, I'd probably recommend steering away from XLS/XLSX files as the source for this kind of thing because they don't provide very nice diffs in version control, which will eventually become an issue. CSV, or some other plain-text format works much better.

    Overall, I've had a great deal of success with this method, but that is contingent entirely upon the fact that my project checks every single box in the 'recommend strongly' field.

    When my app does introduce more complex UI interactions, which happens rarely, test authorship grinds to an immediate halt while I try to sort out how to add support for new interactions, and the length of time that ends up taking is heavily related to how quickly development settles on a design for the new widget.

    Overall, the negative side effects haven't had a strong impact on our release velocity (due mostly to the fact that falling back to bespoke interactions for a handful of elements isn't that hard, it just looks ugly), but they can absolutely ruin the accuracy of my estimates.

    If you're on a young project, I'd steer clear of this sort of idea until the dust settles a bit.

    If you're on an especially dynamic project - Don't do it.



Suggested Topics

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