Continuous Delivery testing in Testing Fundamentals - Build an Automation Script
import requests 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 StagingPage: def __init__(self, driver): self.driver = driver def open(self, url): self.driver.get(url) def is_updated_content_visible(self, expected_text): try: element = WebDriverWait(self.driver, 10).until( EC.visibility_of_element_located((By.XPATH, f"//*[contains(text(), '{expected_text}')]")) ) return True except: return False def verify_ci_build(ci_api_url, build_id, headers): response = requests.get(f"{ci_api_url}/builds/{build_id}", headers=headers) response.raise_for_status() data = response.json() return data.get('status') == 'success' def verify_ci_tests(ci_api_url, build_id, headers): response = requests.get(f"{ci_api_url}/builds/{build_id}/tests", headers=headers) response.raise_for_status() data = response.json() return all(test['status'] == 'passed' for test in data.get('tests', [])) def verify_cd_deployment(cd_api_url, deployment_id, headers): response = requests.get(f"{cd_api_url}/deployments/{deployment_id}", headers=headers) response.raise_for_status() data = response.json() return data.get('status') == 'deployed' def smoke_test_staging(staging_url): driver = webdriver.Chrome() page = StagingPage(driver) try: page.open(staging_url) if not page.is_updated_content_visible('New Feature'): return False # Additional smoke test steps can be added here return True finally: driver.quit() # Example usage ci_api_url = 'https://ci.example.com/api' cd_api_url = 'https://cd.example.com/api' headers = {'Authorization': 'Bearer your_token_here'} build_id = '12345' deployment_id = '67890' staging_url = 'https://staging.example.com' assert verify_ci_build(ci_api_url, build_id, headers), 'CI build failed' assert verify_ci_tests(ci_api_url, build_id, headers), 'CI tests failed' assert verify_cd_deployment(cd_api_url, deployment_id, headers), 'CD deployment failed' assert smoke_test_staging(staging_url), 'Smoke test failed on staging environment'
This script automates the verification of a Continuous Delivery pipeline.
First, it uses requests to call the CI API and check if the build succeeded and all tests passed. Then it calls the CD API to confirm the deployment status.
For the staging environment, it uses Selenium WebDriver to open the application URL and check if the updated content is visible, simulating a smoke test.
The code uses explicit waits to ensure elements are loaded before checking. It separates concerns by having functions for each verification step and a Page Object for UI interaction.
Assertions ensure the test fails clearly if any step does not meet expectations.
Now add data-driven testing with 3 different build and deployment IDs to verify multiple pipeline runs
Practice
Solution
Step 1: Understand Continuous Delivery testing purpose
Continuous Delivery testing aims to keep software ready to release at any time by running automated tests frequently.Step 2: Compare options with the goal
Only To ensure the software is always in a releasable state matches this goal. Other options describe manual or delayed testing, which contradict Continuous Delivery principles.Final Answer:
To ensure the software is always in a releasable state -> Option CQuick Check:
Continuous Delivery = Always releasable software [OK]
- Thinking manual testing is the main focus
- Believing testing happens only after deployment
- Confusing Continuous Delivery with manual UI testing
Solution
Step 1: Identify correct YAML syntax for pipeline steps
Pipeline scripts often use YAML format where keys have colons and nested keys are indented, e.g., 'run_tests: script: pytest tests/'.Step 2: Check each option's syntax
run_tests: script: pytest tests/ uses correct YAML with colon and nested script key. Options A, C, and D miss colons or use invalid assignment.Final Answer:
run_tests: script: pytest tests/ -> Option BQuick Check:
YAML step syntax = run_tests: script: command [OK]
- Omitting colons in YAML keys
- Using equal signs instead of colons
- Not indenting nested keys properly
tests = ['unit', 'integration', 'e2e']
results = []
for test in tests:
if test == 'integration':
results.append('fail')
else:
results.append('pass')
print(results)What will be the output after running this code?
Solution
Step 1: Analyze the loop and conditions
The list 'tests' has three items: 'unit', 'integration', 'e2e'. The loop checks if the test is 'integration' to append 'fail', else 'pass'.Step 2: Determine results for each test
'unit' -> not 'integration' -> 'pass'
'integration' -> equals 'integration' -> 'fail'
'e2e' -> not 'integration' -> 'pass'Final Answer:
['pass', 'fail', 'pass'] -> Option AQuick Check:
Only 'integration' test fails [OK]
- Assuming all tests pass
- Confusing the condition logic
- Mixing order of results
test_step:
script:
- pytest --maxfail=1 --disable-warnings
- echo "Tests completed"However, the pipeline does not stop on the first test failure as expected. What is the likely cause?
Solution
Step 1: Understand pipeline script behavior
In many CI/CD tools, all commands under 'script' run sequentially even if one fails, unless configured to stop on failure.Step 2: Analyze the options and commands
--maxfail=1 is a valid pytest option to stop pytest early, but the pipeline still runs the next command 'echo'. So the pipeline itself does not stop on failure automatically.Final Answer:
The pipeline runs all script commands regardless of failure by default -> Option DQuick Check:
Pipeline runs all script lines unless configured to stop [OK]
- Thinking pytest controls pipeline flow
- Believing echo causes failure
- Assuming invalid option causes issue
Solution
Step 1: Understand test optimization in Continuous Delivery
Running all tests every time can be slow. Detecting changed files and running only related tests speeds feedback.Step 2: Evaluate options for automation and speed
Use a script to detect changed files and run tests related to those files automates detection and selective testing, fitting Continuous Delivery goals. Options B, C, and D are inefficient or manual.Final Answer:
Use a script to detect changed files and run tests related to those files -> Option AQuick Check:
Selective testing on changes = faster feedback [OK]
- Running all tests every time without optimization
- Relying on manual test selection
- Skipping automated tests entirely
Ready to prove it?
Pass the test and this pattern moves unknown
