Test automation pyramid in Testing Fundamentals - Build an Automation Script
from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC class LoginPage: def __init__(self, driver): self.driver = driver self.email_input = (By.ID, 'email') self.password_input = (By.ID, 'password') self.login_button = (By.ID, 'loginBtn') def open(self): self.driver.get('https://example.com/login') def login(self, email, password): WebDriverWait(self.driver, 10).until(EC.visibility_of_element_located(self.email_input)).send_keys(email) self.driver.find_element(*self.password_input).send_keys(password) self.driver.find_element(*self.login_button).click() class DashboardPage: def __init__(self, driver): self.driver = driver self.welcome_message = (By.ID, 'welcomeMsg') def is_loaded(self): return WebDriverWait(self.driver, 10).until(EC.url_to_be('https://example.com/dashboard')) def welcome_text(self): return WebDriverWait(self.driver, 10).until(EC.visibility_of_element_located(self.welcome_message)).text def test_login(): driver = webdriver.Chrome() try: login_page = LoginPage(driver) dashboard_page = DashboardPage(driver) login_page.open() login_page.login('user@example.com', 'Password123!') assert dashboard_page.is_loaded(), 'Dashboard page did not load as expected' welcome = dashboard_page.welcome_text() assert 'Welcome' in welcome, f"Expected 'Welcome' in message but got '{welcome}'" print('Test passed: Login functionality works as expected.') finally: driver.quit() if __name__ == '__main__': test_login()
This script uses Selenium WebDriver with Python to automate the login test case.
We define two page classes: LoginPage and DashboardPage to separate page interactions, following the Page Object Model.
The LoginPage class has methods to open the login page and perform login by entering email and password and clicking the login button. We use explicit waits to wait until the email input is visible before typing.
The DashboardPage class checks if the dashboard URL is loaded and retrieves the welcome message text, again using explicit waits.
The test_login function runs the test: it opens the login page, performs login, then asserts the dashboard page loaded and the welcome message contains 'Welcome'.
Finally, the driver quits to close the browser.
This approach avoids hardcoded sleeps, uses maintainable locators by ID, and keeps assertions clear and focused.
Now add data-driven testing with 3 different sets of valid credentials to verify login works for multiple users.
Practice
test automation pyramid?Solution
Step 1: Understand test types and speed
Unit tests are fast and cheap, integration tests are slower, UI tests are slowest and costly.Step 2: Apply pyramid principle
The pyramid suggests many unit tests, fewer integration tests, and few UI tests to catch bugs early and keep tests efficient.Final Answer:
Write many fast unit tests, fewer integration tests, and few slow UI tests -> Option BQuick Check:
Test automation pyramid = many unit, fewer integration, few UI tests [OK]
- Thinking UI tests should be the majority
- Believing manual tests replace automation
- Assuming all test types should be equal
Solution
Step 1: Recall test speed hierarchy
Unit tests run fastest because they test small code parts, integration tests are slower, UI tests are slowest due to full system interaction.Step 2: Match order from fastest to slowest
The correct order is unit tests first, then integration tests, then UI tests last.Final Answer:
Unit tests, integration tests, UI tests -> Option DQuick Check:
Speed order = unit < integration < UI [OK]
- Confusing UI tests as fastest
- Mixing integration and unit test order
- Ignoring test execution speed differences
Solution
Step 1: Analyze test counts
There are many unit tests (100), fewer integration tests (30), and very few UI tests (5).Step 2: Compare with pyramid principle
The pyramid recommends many unit tests, fewer integration tests, and few UI tests, matching this distribution.Final Answer:
It follows the pyramid by having many unit tests and few UI tests -> Option CQuick Check:
Test counts match pyramid shape [OK]
- Thinking 5 UI tests is too many
- Confusing integration test count importance
- Assuming equal test numbers are correct
Solution
Step 1: Understand test cost and speed
UI tests are slow to run and expensive to maintain compared to unit tests.Step 2: Identify pyramid violation
Having mostly UI tests means slow feedback and higher maintenance, which the pyramid warns against.Final Answer:
UI tests are slow and costly, causing slow feedback and maintenance issues -> Option AQuick Check:
Too many UI tests = slow, costly [OK]
- Ignoring unit test importance
- Assuming integration tests cover all bugs
- Confusing manual and automated UI tests
Solution
Step 1: Analyze current test distribution
There are few unit tests (10), many integration tests (50), and many UI tests (20), which is opposite of pyramid advice.Step 2: Apply pyramid principle for improvement
The pyramid suggests many unit tests, fewer integration tests, and few UI tests to catch bugs early and keep tests efficient.Final Answer:
Increase unit tests significantly, reduce UI tests, and keep integration tests moderate -> Option AQuick Check:
More unit, fewer UI tests = pyramid aligned [OK]
- Adding more UI tests instead of unit tests
- Removing unit tests thinking they are less useful
- Ignoring test speed and cost differences
Ready to prove it?
Pass the test and this pattern moves unknown
