This tutorial will make web UI testing easy. We will build a simple yet robust web UI test solution using Python, pytest, and Selenium WebDriver. We will learn strategies for good test design as well as patterns for good automation code. By the end of the tutorial, you’ll be a web test automation champ! Your Python test project can be the foundation for your own test cases, too.
- You’re here → Set Your Test Automation Goals (Chapter 1)
- Create A Python Test Automation Project Using Pytest (Chapter 2)
- Installing Selenium WebDriver Using Python and Chrome (Chapter 3)
- Write Your First Web Test Using Selenium WebDriver, Python and Chrome (Chapter 4)
- Develop Page Object Selenium Tests Using Python (Chapter 5)
- How to Read Config Files in Python Selenium Tests (Chapter 6)
- Take Your Python Test Automation To The Next Level (Chapter 7)
- Create Pytest HTML Test Reports (Chapter 7.1)
- Parallel Test Execution with Pytest (Chapter 7.2)
- Scale Your Test Automation using Selenium Grid and Remote WebDrivers (Chapter 7.3)
- Test Automation for Mobile Apps using Appium and Python (Chapter 7.4)
- Create Behavior-Driven Python Tests using Pytest-BDD (Chapter 7.5)
Many software approaches are “driven” by some sort of objective. Test-driven development makes developers write tests before they write product code. Behavior-driven development encourages teams to define features as specs with examples. I’d like to introduce a new phrase: goal-driven testing.
Before laying a finger on your keyboard to write any tests, ask yourself one question: What are my goals with testing? Testing is a healthy practice, but we don’t test for testing’s sake. Testing is a means to an end: quality. Teams should decide what aspects of quality matter most to them and then enact an appropriate testing strategy. For example, consider some goals and strategies for web app testing:
|90% of all features have basic test coverage.||Use a code coverage tool with unit tests.|
|Web pages have sub-second page loading times.||Use performance testing tools to measure page load times.|
|Developers are notified within 2 hours of new regressions.||Set up continuous testing as part of the delivery pipeline.|
Web apps are designed for human users who interact with pages visually and never see the code underneath. Thus, web UI testing is meant to cover user-like interactions in a real browser. Web UI tests are truly end-to-end because everything behind the front-end site – the services, the databases, and any other systems – must be up and running to support the full app. They answer one big question: Do web app features actually work? They are an indispensable part of a robust web app testing strategy.
Thankfully, web UI tests can be automated for consistency, repeatability, and speed. Packages like Selenium WebDriver enable programmers to automate browser interactions with languages like Java, C#, and Python. More advanced tools like TestProject provide a full platform out of the box for recording, refactoring, and reporting web UI tests.
Web UI testing has drawbacks, though:
- Web UI tests are slow, even when automated. They need time to open a browser, load pages, and send interactions. A typical automated web UI test takes about a minute to complete, whereas a typical unit test takes a millisecond.
- Web UI tests cannot pinpoint failures in the code like unit tests can. For example, a web UI test could reveal where string formats are displayed incorrectly, but it cannot point to the specific method, file, and line number at fault.
- Web UI tests can be flaky. Any black box test relies upon the system under test. Race conditions and halting problems are simply to be expected. Test automation code needs careful design and safety checks to become robust.
In short, web UI tests are expensive: they require time, expertise, and maintenance.
The best way to mitigate these drawbacks is to balance the testing strategy with return on investment. Not every feature should have a Web UI test. Instead, focus on the most critical features, and stick to “happy” paths rather than edge cases. Make sure to run solid coverage with tests at the unit and integration levels, too, to catch bugs early. More coverage at lower layers means less risk at higher layers, which in turn means fewer web UI tests are needed.
This tradeoff is best illustrated by the renowned Testing Pyramid:
The Testing Pyramid encourages teams to balance high-level, expensive tests (like web UI tests) with more low-level, fast, simple tests (like unit tests or web service API tests).
Our goals for this tutorial are straightforward:
- Learn the basics of web UI test automation with Python.
- Set up a good Python test automation project that can be extended with new tests.
- Write and run a few example tests locally.
As such, we will focus exclusively on web UI testing.
If you’re ready to start coding, then jump into the next chapter!