UI Testing

This is a part of System Testing, or end to end testing.
This is the blackbox testing of a product through its user interface and feature testing since it exercises workflows like a user. It is end-to-end because all parts are exercised together. The goal is to catch regressions that Unit Testing and Integration Testing miss.

Focus

• Critical business flows like signup, login, checkout, and payments
• The primary way users use the feature and a few key edge cases
• Do not test redundant pointless, or unimportant variations

Types of Testing

• Functional E2E verifies the critical user flows and that they produce the correct outcomes
• Visual regression detects unintended UI and layout changes
• Accessibility checks usability to people with disabilities
• Cross browser and device ensure consistent behaviour across different browsers

Frameworks

• Selenium
• Playwright

Contains

1. Locators (how we find elements)
2. Actions (what to do)
3. Assertions (what to expect)

Typical Assertions

• Element state (visible, selected, etc)
• Content (text contains, etc)
• Navigation
• Collections (num of rows, or list contains a value)
• Negative checks: element not present, not visible, etc Good Practices
• Assert user-visible outcomes rather than internal implementations
• Prefer stable signals
• Write one clear primary assertion per step plus a final goal assertion
• On failure, capture evidence (you can record tests with both frameworks listed here)

Race Conditions

There are for some reason common in UI tests. Test code runs in milliseconds, where the web page renders in seconds. Finding a button and clicking it may result in different results.

UI tests often need waiting. Modern web UIs are asynchronous, so elements appear, change, and disappear over time. Without waiting, tests become flaky even with correct locators, actions, and assertions. Waiting means synchronizing the test with the app’s real state. Avoid sleep and wait for conditions instead. Use explicit waits (in Selenium).

Creating UI Tests

1. Write the scenario / intent in natural language or Gherkin (describe intent, not how the code works)
2. Identify stable locators for the elements involved
3. Write the code to match the intent

AAA Pattern

1. Arrange: set up data and navigate to starting page
2. Act: perform the user actions
3. Assert: verify outcomes in the UI, URL, or app state
4. Cleanup: reset state or use fresh context

Page Object Model

• UI tests are stateful and often require shared steps
• Without structure, tests duplicate locators and steps across many files
• Duplication leads to high maintenance cost when the UI changes
• Create a page object per page that encapsulates locators and actions
• When the UI changes, update the page object once instead of fixing many tests