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

Architecture for test frameworks

Architecture for test frameworks

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