
- About me (Instructor)
- The Testing Talks Hub Difference
- Automation Framework Technology Stack
- The Power of Playwright Automation Framework
- Building a world-class automation framework with Playwright
- High Level Course Overview
- Key Online Resources to bookmark
- Some tips before taking the course
- Let’s connect
We look at why automation framework architecture matters and the power of the automation framework you will build as part of this course.
- Why automation framework architecture matters
- The importance of building a 'Proof of Concept' automation framework
- How to leverage your wider team to help build a robust automation framework
- Key object-orientated design principles to use across your frameworks
- How this architectural approach can support multiple automation frameworks
- Finally, Some key observations (Successes and Challenges)
- How to download and install Node
- Adding Node to your system $PATH (if required)
- Downloading and Installing your first (IDE) Integrated Development Environment
- Essential Cucumber Plugins for your (IDE) Integrated Development Environment
- Downloading and Installing VSCODE
- Installing the Cucumber (Gherkin) Full Support Plugin
- Adding a VSCODE settings.json file
- Adding the the ability to step into cucumber scenario steps via the settings.json
- Stepping into our cucumber feature step definition
- SSH Keys & Cloning your first GitHub repository
- Yarn install packages for our react application
- Yarn start our locally running react application
- Creating our e2e folder within our react application project structure
- Initialising our package.json and tsconfig.json
- Yarn installing Playwright/test, Cucumber, TypeScript, ts-node and @types/node
- Best practices - Automation folder structure
- Creating our first TypeScript file - Hooks.ts
- Setting up our hooks for Before, BeforeAll, AfterAll and After
- Introducing the concept of Browser, Context and Page with regards to Playwright Framework
- Importing our Cucumber & Playwright packages for the first time
- Creating our first Feature file and Cucumber scenario
- Creating our first step definitions (navigation and assertion)
- Introducing the use of console log our step definitions
- Leveraging playwright page.goTo function to navigate to a page
- Our first text equals assertion using playwright/test
- Hooking up our cucumber run script within package.json
- Running our first automation test via the terminal
- Key Learnings for module 2
- Running our tests in IntelliJ using an npm plugin configuration
- Introducing different Cucumber @tags and their purpose
- Updating our package.json with @tag specific cucumber run scripts
- Running our automation tests using different @tags
- Understanding the benefit of passing parameters via cucumber steps
- Leveraging Regex to pass parameters within a Cucumber step
- Console logging our Cucumber step parameters leveraging string concatenation
- Implementing more flexible regex for text-based assertions
- Inspecting elements in our react application using developer tools
- Adding our first element locator to the react application codebase
- Introduce a new assertion cucumber step to check if the element is displayed
- Playwright locator function implemented to retrieve and store a locator object based on our element attribute
- toBeVisible leveraged from Playwright/test to determine if our element is visible
- Developing a deeper understanding of Hooks and how they work
- Understanding what HEADLESS mode is and seeing it first hand by running an automation test
- Understanding the power of running automation tests with segregated context
- Reviewing our understanding of Browser, Context and Page
- Key learnings for module 3
- Screenshots generated on test failure
- Automation tests recorded for each test run
- Screenshots and Recordings being stored in a generated reports folder
- Understanding the benefits of Cucumber World
- Implementing Cucumber World and initialising our Browser, Context and Page as Screen
- Implementing our own custom newBrowser function to return our browser object
- Adding our env function to parse and determine if our expected ENV variable is present or not
- Enabling the ability to run our automation tests across different browsers (Chromium, Webkit, Firefox)
- Refactoring and simplifying our hooks.ts to leverage our new world functions
- Levering .this in Cucumber World to pass our screen object between Cucumber Steps
- Adding our UI_AUTOMATION_BROWSER to customise the browser we run our automation tests against
- Running our first automation suite on a new browser - firefox & webkit
- Enabling our automation framework to pass global configuration via Cucumber World
- Implementing Babel to compile TypeScript to JavaScript to overcome cucumber.js lack of support for es6 or TypeScript
- Refactoring and reducing duplication in our package.json script
- Single cucumber script in package.json that is --profile enabled
- Passing dynamic cucumber arguments via our new index.ts
- Moving away from cucumber.js plugin and leveraging an NPM configuration
- Running our automation tests via a yarn cucumber script with a @tag profile
- Understanding the benefits fo ENV files for better environment variable management
- Implementing DotEnv for passing ENV files to the global process.ENV
- Leveraging ENV variables to replace static paths and file names in our automation framework
- Running our automation tests to validate and verify our changes to our automation framework
- Implementing cucumber-html-reporter for our automation suite reporting
- Levering ENV variables to set our JSON & HTML report files
- Attaching our screenshots to our test report on failure via the After hook
- Pre and Post scripts to handle generating our required report folders and test reports for each automation suite run
- Creating our own dynamic run_tests bash script to make test execution easier from the terminal
- Reviewing our cucumber-html-report on test pass and failure.
Windows users only:
- Why the run_tests.sh returns a COMMON_CONFIG_FILE command error
- Creating our run_tests.bat file to run our automation suite on windows
- Updating our pacakge.json to remove COMMON_CONFIG_FILE references
- Updating our run_tests.sh file with our export COMMON_CONFIG_FILE
Many of students reached out asking how we can run our automation suite with npm instead of yarn.
- Consistent exporting of COMMON_CONFIG_FILE across .bat and .sh files
- Refactoring the structure of our package.json scripts
- Updating our yarn references to npm
- Adding additional double dashes to enable passing multiple arguments with npm
This new order we call our scripts inside package.json also resolves the "TypeError: suite.features.forEach is not a function" that some students had reported seeing - especially if you attempted to run the suite with no tests.
Key Learnings for module 4
- Understanding the value of mappings when building an object-orientated and reusable automation framework
- Implementing our first global.ts types definition file and creating types for our pages and hosts config
- Creating our hosts.json file containing our localhost URL
- Creating our pages.json file containing our home page ROUTE
- Adding hosts configuration and pages configuration to Cucumber World
- Initialising our hosts and pages configuration within our index.ts
- Retrieving hosts and pages json at runtime and storing it all as an object
- Passing our global config world parameters via our dynamic cucumber arguments inside index.ts
- Replacing our pageId string type with our new global PageID type
- Retrieving our globalConfig within our step definition by leveraging Cucumber World .this
- Developing our navigateToPage function
- Passing our global pagesConfig and hostsConfig to our new function
- Retrieving our host URL and page Route from global config based on our cucumber parameters
- Leveraging playwright goto function to then navigate to our page
- Running our automation test to validate our new global configuration and mappings are working as expected
- Understanding the value of mapping our page elements
- Adding our ElementKey and ElementLocator to our global.ts type definitions
- Creating our pageElementMappings global.ts type definition
- Adding global variables to our global.ts types definition
- Initialising our pageElementMappings json files at runtime and storing them as object
- Storing each page element mapping .json as respective objects based on pageId at runtime inside
- Setting our current page ID on navigation to page to globalVariables current screen
- Pass our new global variable for the current screen to our steps via Cucumber World
- Creating our new getElementLocator function to retrieve our element mapping from the .json file based on our current page name
- Introduce the ability for our getElementLocator to also find our element mapping inside a new common.json designed for attributes that might be common across multiple pages
- Add our new ENV variable for where we will store all our element mapping json files
- Adding our mappings within our home.json and common.json mapping files
- Running our automation test to validate our changes have been successful
- Updating our existing step definitions that interact with an element to leverage our getElementLocator function
- Running our automation suite to validate that everything is working as expected.
- Understanding why implementing our own custom waitFor can be a powerful mechanism to further ensure stability when running your automation suite on an environment.
- Developing and deep-diving into our waitFor function - Understanding how it works and how we can set timeout and retry times.
- Removing playwright@test and replacing it with native assertions
- Running our automation test and testing out our new waitFor function
- Introducing a default timeout across our suite that exceeds our waitFor timeout
- Creating a new envNumber function to convert our ENV variables from string to number
- Verifying that our waitFor will retry until our respective timeout is hit.
- Refactoring our existing steps to leverage our new waitFor function
- Running our automation suite to check our new changes have not broken anything
Key Learnings from module 5
- Create our new current Path Matches Page Id function to test if our browser URL matches our pageId regex within page.json
- Leveraging our waitFor function to retry until our URL matches our pageId regex within page.json
- Removing our current screen global variable for a better solution
- Creating our new getCurrentPageId function to retrieve our pageId based on matching the current page URL to a Regex found within our pages.json
- Leveraging the TypeScript Object.keys and .find function to retrieve our pageId from pages.json
- Refactoring our getElementLocator to leverage our new getCurrentPageId function
- Debugging via console.log our new get getElementLocator function to deepen our understanding
- Running our automation tests to validate our pageId is updating in realtime as we transition between pages
- Create our new click button step definition
- Create our new click button step definition leveraging our getElementLocator function
- Introduce playwright waitForSelector function to determine if our element is visible
- Introducing html-behavior to house our html interaction functions leveraging playwright
- Adding our directed to step to add additional stability when navigating around the application
- Leveraging our waitFor function inside our new directed to navigation step
- Validating our automation test can run function and update our pageId across multiple page transitions.
- Developing our fill in the form input step
- Building our step leveraging our console log, getElementLocator and custom waitFor function
- Adding our new inputValue function within HTML behaviour to focus and fill our input using Playwright
- Run our automation test and validate our new form step
- Double-checking our automation suite is functioning as expected in HEADLESS mode
- Developing our select the option in form step
- Building our step leveraging our console log, getElementLocator and custom waitFor function
- Adding our new selectValue function within HTML behaviour to focus and selectOption
- Run our automation test and validate our new form step
- Seeing how we can now leverage our reusable Cucumber steps to automate out our form functionality
- Adding our respective form mappings and building out our first end to end automation test
Key Learnings from Module 6
- Understanding common reasons for test failures
- Some of the different debugging techniques available
- How to launch Playwright Inspector when we run our automation tests
- Playwright Inspector functionalities - Stepping through our automation test
- Pausing our tests with playwright's page.pause() function
- Understanding the power of Developer tools
- Introducing a failure into our automation suite
- Adding a new should equal the text assertion step definition
- console logging our saved contact object within our react application
- Enabling Chrome Developer Tools by default when our automation tests run
- Viewing our saved contact object via the console within Chrome Developer Tools
- Introducing debugger to our react application code and digging into the code via Chrome Developer Tools
- Using console.logs to debug our automation framework code
- Console logging our expected vs actual text and reviewing our console logs
- Introducing breakpoints to our code and using the IntelliJ debugger tool to step through our automation code
- The value of our cucumber reporter for debugging test failures
- Drilling down to the exact step failure within our cucumber reporter
- Reviewing our screenshot on failure within our cucumber reporter
- How to silence the cucumber publish message generated by cucumber reporter
Key Learnings for Module 7
- Introducing the Playground
- Understanding our approach to automating radio buttons
- Develop a new step definition to assert if a radio button is checked.
- Introduce a new interaction step definition to check a radio button
- Create a new checkElement function within our HTML behaviour to .check our radio button
- Develop an automation test that can test switching radio buttons is working as expected.
- Introducing the concept of negate into our Cucumber step definition
- Reducing duplication of step definitions by enabling the ability to assert on should and should not
- Refactoring our radio button scenario to leverage negate and more deeply test the functionality.
- Expanding negate across all our current assertion step definitions
- Refactoring our create contact scenario to leverage negate and more deeply test our functionality
- Discuss how we will further expand our Negate to interaction steps to ensure no repetition of code within our automation framework.
- Adding an automation test to interact with and assert on our AutoComplete component
- How to debug AutoComplete inputs with developer tools
- Creating our new contains the value step for use with form inputs
- Leveraging negate, getElementLocator, waitFor and native assertions to build a new consistent step definition
- Developing our getValue function within HTML behaviour to return our element value
- Mapping input id, text and values (Adding identifiers outside of data-id to our .json mapping files)
- Automation test input with different states - Active & Disabled
- Adding a new step to assert that our input equals the value
- Adding an automation test to validate our respective input equal the expected value
- Adding a new step to assert that our input is enabled or disabled
- Expanding on our input test to validate that our disabled and enabled inputs are as expected
- Adding a new automation test to validate our input validation error message
- Expanding on our common cucumber arguments in index.ts to take in our parallel and retry parameters
- Adding our PARALLEL and RETRY ENV variables to our common.env
- Running our automation suite in parallel and validating parallel and retry are working as expected
Key learnings for module 8
- The difference between checkboxes and radio button
- Adding a new automation test to interact with and assert on Checkboxes
- Updating our radio button step definitions to accept checkboxes via Regex
- Enabling our Check step definition to both check and uncheck radio button and checkboxes using Regex
- Creating our new unCheck function within HTML Behaviour to uncheck element using playwright
- Updating our checkboxes automation test to uncheck and assert on our now unchecked checkbox
- Understanding how Playwright works and interacts with IFrames
- Creating a new automation scenario with the intention of interacting and asserting on Iframes
- Creating a new form input step designed for IFrames
- Developing our new getIframeElement function which will return our element content frame
- Adding our new inputValueOnIFrame function within HTML behaviour to fill in input
- Running our automation test to validate our Iframe form field is being interacted with and filled in with text
- Adding our first IFrame assertion step definition to ensure an element on IFrame is displayed
- Adding our Iframe assertion step definition to ensure an element contains the text as expected
- Running our automation test to validate our Iframe assertion steps are working as expected
- Adding our Iframe assertion step definition to ensure an element equals the text as expected
- Building out the rest of our end to end automation test leveraging our new IFrame steps
- Understanding why separate steps for IFrame was the cleaner and less complicated solution for our automation framework.
- Why Playwright makes our life easier to automate New Tabs and Windows
- Creating a new automation scenario with the intention of interacting and asserting on tabs
- Passing our desired page index through our cucumber scenario and converting it to Number
- Creating our new tab should contain the title assertion step definition
- Adding our new title assertion steps to our tabs Cucumber scenario
- Creating our new fill in the form input on tab step definition
- Developing our new inputValueOnPage function with HTML Behaviour to focus and fill our pages element input
- Updating our tabs Cucumber scenario to validate our new form step is working on the tab as expected
- Creating a new general step to simply wait an expected amount of time (For debugging purposes)
- Adding our new step element should be displayed on tab step definition
- Updating our tabs Cucumber scenario to validate our new form assertion step is working on the tab as expected
- Adding our tab assertion step definition to ensure an element equals and contains the text as expected
- Building out the rest of our end to end automation test leveraging our new tab steps
- Understanding why separate steps for tabs was the cleaner and less complicated solution for our automation framework.
- Updating our new tab interaction and assertion steps to work with new windows via Regex
- Copy and paste our Tab Cucumber Scenarios across to our new windows.feature
- Refactor our automation test to interact with the new window button
- Find and replace all our tab references and update to window across our windows.feature
- Quickly add multiple new automation tests to an entirely new functionality (new window) in minutes.
Key Learnings for module 9
- Adding an automation test that interacts with links
- Updating our click interaction step definition to enable button or link using Regex
- Running our link Cucumber scenario to verify our change is working as expected
- Adding an automation test that can interact with buttons (with the same element identifier) at Index
- Creating our new click element at index interaction step - leveraging regex to pass our desired index as a parameter.
- Creating our new clickElementAtIndex within our HTML behaviour
- Running our automation test to validate our button is being clicked at index
- Adding a new assertion step definition to assert on the text at index containing text
- Validating our button at index contains our expected text by running our automation test
- Building out our automation test to interact and assert on multiple buttons at respective indexes
- Understanding the power of cucumber Data Table to pass in our expected table data to our Cucumber table assertion step
- Creating our new table should equals the following Data Table step definition
- Understanding the respective Data Table functions we can access via the Cucumber framework
- Creating a function to return our HTML table data rows for use in our Cucumber table assertion step definition
- Adding our new Cucumber step definition to our Cucumber Scenario and matching up our Data Table to our HTML table data
- Running our automation test to validate that our new table step definition is working as expected
- Debugging our new table step definition to validate the data coming through our Data Table and HTML table
- Adding a should not equals the following Data Table step to our cucumber scenario
- Running our automation test to validate our table scenario is working as expected
- Starting to experience how we can add entirely new scenarios for new features by leveraging existing step definitions.
- Enabling our radio button/check box steps to interact and assert on switches by updating our step Regex
- Running our new switch automation test to validate our changes are working as expected
Key learnings from module 10
This course has been designed to simulate a real-world experience in building a Cucumber, Playwright & TypeScript automation framework from the ground up for a fully-featured application.
Upon completion, you will be able to apply your learnings and the automation framework you have built into your respective companies and projects. We are confident you will become an expert in building a world-class automation framework.
Our course and the automation framework we will build together has been developed with guidance from some of the globes leading testing and software engineering professionals and because of that we believe we can offer an incredible course where we will:
- Develop your automation framework against a real react application running on your local machine.
- Build an end-to-end automation framework from the ground up for a full-featured end-to-end react application.
- Evolve your skills and continuously improve your automation framework as we progress through the course
- Learn how to build an object-orientated – engineer reviewed and approved automation framework.
We want this course to be the best decision you have ever made for your personal growth when it comes to improving your knowledge and skills in test automation framework architecture.
Across many hours of exciting content I will be at the bottom right of your screen instructing and cheering you along throughout the course. You will have everything you need to learn how to build a world-class automation framework.
----------- New Course Added in 2023 -----------
Happy New Year to all our wonderful students!
Playwright introduced the ability to support standalone API automation testing as part of the version 1.16 upgrade. Playwright is now considered a formidable option when selecting a great open-source automation framework for API Testing.
Many of our students reached out asking if we could consider updating the course with a some new lectures on how to build a Cucumber, Playwright and TypeScript API Automation Framework.
We have taken it a step further - By adding a comprehensive new course on the subject within your existing Build a Cucumber Playwright TypeScript Automation Framework course.
From Section 24 - 5+ hours of new content!
Rest API Testing (Automation) with Playwright & TypeScript
- Plan and roadmap your automation coverage with Postman.
- Develop your API automation framework against a real API.
- Build two end-to-end automation frameworks (Playwright + JavaScript & Cucumber, Playwright & TypeScript) from the ground up for a full-featured end-to-end API.
- Evolve your skills and continuously improve your automation framework as we progress through the course
- Learn how to build an object-orientated – engineer-reviewed and approved automation framework.
If you enjoy the new course all we ask for in return is a kind review! We will continue to bring amazing updates like this in the future. :)