How to Run Visual Tests with Python and TAU
Add visual checkpoints to Python and Selenium tests with Applitools Eyes. Learn how to review baselines, choose comparison modes, and troubleshoot mismatches.
To run visual tests with Python and TAU (Test Automation University), use the course’s web-testing stack: Python, Selenium, and the Applitools Python SDK. Drive the application to a meaningful state, add a visual checkpoint, and review any difference against an accepted baseline. Keep functional assertions too: they check behavior, while visual comparison can reveal rendering changes that behavior checks miss.
TAU here means Test Automation University, not the University of Oregon’s Tuning and Analysis Utilities performance toolkit. The sources identify the course stack but do not verify current installation commands, package versions, or method signatures. Treat the workflow below as the implementation map, then use the current course and official Applitools documentation to confirm executable setup and API details before adopting it.
1. Understand the workflow
- Set up the test context. Use Python and Selenium to launch the application in a controlled browser environment. The course review lists Python 3 and an IDE among its prerequisites and describes setting up Eyes; its review dates to 2020, so do not rely on it for current installation instructions.
- Automate a representative journey. Navigate and interact as a user would. For example, the course review describes a bookstore flow that reaches a result page.
- Assert behavior. Keep normal checks for outcomes such as a search result, expected text, or a successful action.
- Capture a visual checkpoint. Record the rendered state with the visual testing SDK. The checkpoint is compared with an accepted baseline on later runs.
- Review differences. Decide whether each change is an unintended regression or an expected product update before accepting a new baseline.
A visual mismatch is a signal to inspect, not automatic proof of a defect. A functional assertion can pass while a color, spacing, or other visible detail has changed; a screenshot comparison helps surface that change.
2. Add a checkpoint to a Python and Selenium test
The course lesson identifies Selenium with the Applitools Python SDK. Exact SDK calls and current setup are not established by the research available for this article, so this is a runnable Selenium journey skeleton—not a complete Eyes integration. Add the checkpoint using the current official SDK instructions for your chosen language and version; do not copy guessed method names into a test suite.
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.support.ui import WebDriverWait
# Configure the browser driver using the current Selenium setup
# for your environment.
driver = webdriver.Chrome()
try:
driver.get("https://example.com")
# Wait for the state that matters instead of relying on a fixed delay.
WebDriverWait(driver, 10).until(
EC.visibility_of_element_located((By.TAG_NAME, "h1"))
)
# Functional assertion: confirm the journey reached the right state.
heading = driver.find_element(By.TAG_NAME, "h1").text
assert heading, "Expected the page heading to be visible"
# Add the Applitools Eyes visual checkpoint here, following the
# current official Python SDK documentation. Choose a stable name
# for the test and checkpoint so later runs compare consistently.
finally:
driver.quit()Replace the example page and assertion with an application route and user journey that matter. For a real Eyes test, follow the current official setup for credentials, SDK lifecycle, test and checkpoint naming, and closing the test so results are reported. The source dossier does not establish these current API details, so this article intentionally does not invent an Eyes code sample.
3. Choose what the checkpoint should compare
The Applitools course review describes four comparison modes. Their choice depends on what matters to the test and how much rendering variation is acceptable; the review describes Strict as the course’s typical choice, not a universal rule.
| Mode described in the review | Useful when | Consider |
|---|---|---|
| Exact | Pixel-level changes themselves matter. | It is sensitive to rendering noise and small differences. |
| Strict | You want visual comparison that tolerates some pixel variation. | Review flagged differences; do not assume tolerance means every change is harmless. |
| Content | Content matters more than color differences. | It may be a poor fit when color is part of the requirement. |
| Layout | Structure and arrangement matter, while content is dynamic. | Use it where changing text or data should not make the whole checkpoint noisy. |
Also choose the capture scope deliberately: a viewport, a whole page, or a selected region answer different questions. The course review also discusses regions inside iframes, grouping checks into batches, PDF visual validation, result analysis, and integrations. Confirm exact support and API calls in current documentation before building those into a suite.
4. Make visual checks stable and useful
- Wait for the state, not an arbitrary pause. Wait for a meaningful element or application condition before capturing. A fixed delay can be too short on a slow run and waste time on a fast one.
- Control dynamic content. Where possible, use deterministic test data and a stable test account. Identify timestamps, rotating content, or personalized areas that can create expected differences.
- Keep checkpoint names consistent. Stable test and checkpoint identities make comparisons over time easier to interpret.
- Keep behavior checks. A screenshot comparison does not replace assertions that a form submitted, a link navigated, or the right data loaded.
- Review before baseline updates. Inspect the changed area and decide whether the new appearance is an accepted product change. Update only after that decision.
- Start with important journeys. Cover a small number of high-value screens first, then expand to regions, responsive states, or additional documents where the current SDK supports them.
5. Troubleshoot common problems
| Symptom | Likely cause | What to do |
|---|---|---|
| The visual checkpoint differs on every run. | Dynamic content, timing variation, or an unstable page state. | Wait for the relevant state, stabilize test data, and inspect whether changing regions should be excluded or compared with a more suitable mode supported by the current SDK. |
| The browser captures before the page is ready. | The test navigated but did not wait for the content used by the checkpoint. | Wait for a meaningful element or application-specific ready condition before capture. |
| A functional test passes but the visual check fails. | Behavior can remain correct while appearance changes, such as a color or layout shift. | Inspect the diff at the affected region; determine whether it is a regression or an accepted change. |
| A visual check passes despite a behavior problem. | The rendered image does not prove that every interaction or business rule worked. | Retain and strengthen functional assertions alongside visual checkpoints. |
| The baseline changes unexpectedly. | A new appearance may have been accepted without review, or the test may be capturing a different state. | Check the journey, viewport, data, and checkpoint identity; review the change before accepting a baseline. |
| SDK setup or calls do not match an example. | Older course-review material may not match current package APIs or compatibility requirements. | Use current official Applitools documentation and the current TAU lesson for installation, supported versions, and API signatures. |
6. Performance, reliability, and cost considerations
Every browser journey and visual checkpoint adds work to a test run. Keep the suite focused on valuable states, avoid unnecessary fixed waits, and use batching only where the current integration supports it and the resulting reports remain easy to review. The dossier provides no verified runtime benchmarks, current service pricing, or compatibility matrix, so those should be checked in current official documentation.
For reliability, make the captured state reproducible: use stable data, wait on state, keep viewport and browser configuration consistent, and review changes before updating expected images. Treat screenshots as evidence about rendering, with functional checks providing evidence about behavior.
Or skip the browser setup
For a one-off page capture or a screenshot workflow that does not need Selenium orchestration, ScreenshotNeo provides a website screenshot API and MCP server. It can return PNG, JPEG, WebP, or PDF from one GET request. See the API documentation for request options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo accepts cookie or consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, and failed loads are not billed, and cache hits cost nothing; response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. Every feature is on every plan. This is useful for capturing pages, while Selenium plus a visual testing service remains the workflow for automated baseline comparisons.
Sign up for ScreenshotNeo’s free plan: 1,000 screenshots a month, no card required.
FAQ
Does TAU mean the Tuning and Analysis Utilities toolkit here?
No. In this title it means Test Automation University, whose course covers Python visual testing.
Does a visual test replace Selenium assertions?
No. Keep functional assertions for behavior and use visual checkpoints to assess rendered output.
Should every mismatch cause a baseline update?
No. First decide whether the visual change is a defect or an accepted product change.
Which comparison mode should I choose?
Choose based on whether pixel changes, visual appearance, content, or layout matter most. The course review reports Strict as its typical choice, but the right mode depends on the test.
