Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Architecture for test frameworks

Architecture for test frameworks

Avatar for Sven Kroell

Sven Kroell

December 05, 2017
Tweet

More Decks by Sven Kroell

Other Decks in Programming

Transcript

  1. Sven Kroell Testing Toolsmith 5 Years in Automation Working for

    Novoda Mentoring new Testers Creating tailored solutions @craftingtester 2
  2. Repairing on the fly 1 0 Checks get deactivated Hard

    to understand Red builds Codebase grows
  3. ➡ Separation of concerns ➡ Build a domain language ➡

    Keeping the checks simple ➡ Reusable components Why a framework 1 3
  4. ➡ Orchestrate the checks ➡ No states ➡ KISS ➡

    Using a DSL provided by the framework Checks (Testfiles) 1 7
  5. Layers of the Framework 1 8 Checks Driver Repositories Workflows

    Page Objects Data Generators Data
 Access Objects
  6. ➡ Hold the states ➡ Fetch data from api ➡

    Trigger builder Repositories 1 9
  7. ➡ Centralised data generation ➡ Single point of change ➡

    Checks don’t need to know data rules Why repositories? 2 1
  8. ➡ Decouple flows from checks ➡ Checks get cleaner ➡

    Using a DSL makes it easier for new joiners to get up to speed Why workflows? 2 4
  9. ➡ Holds information about one component of the page ➡

    Write and Read from a certain elements Page Objects 2 5
  10. ➡ Hides complexity of the DOM from workflows ➡ Single

    point of change for identifiers Why Page Objects? 2 7
  11. ➡ Errors != Faults != Failures ➡ Plan your checks

    ➡ Work closely with your devs Remarks 2 9
  12. ➡ Creating checks is software development ➡ Clean code is

    very important ➡ A good architecture helps while refactoring Final thoughts 3 0