Your First Selenium Script
The clearest way to understand Selenium is to write the smallest script that actually does something: open a browser, navigate to a page, interact with an element, and read back a result. A first script typically opens a search engine, types a query into the search box, submits it, and checks that the resulting page title contains the expected text — small enough to run in seconds, but touching every core WebDriver concept: session creation, navigation, element location, interaction, and teardown.
Cricket analogy: A minimal end-to-end script mirrors a net session's simplest complete drill: walk in, face one over, check if you middled the shots — small enough to run quickly but touching stance, timing, and shot execution just like a full innings would.
Launching a Browser and Navigating
The script begins by instantiating a driver object — webdriver.Chrome() — which starts a real Chrome process and establishes a WebDriver session, as covered in the architecture topic. Calling driver.get('https://example.com') sends a navigation command and, importantly, blocks until the browser reports the page has finished loading according to the document.readyState, not until every asynchronous resource like an image or ad script has finished — which is why interacting with dynamically loaded content immediately after get() is a common source of flaky failures.
Cricket analogy: driver.get() waiting for readyState but not every late asset is like an umpire signaling 'play' once the pitch is officially ready, even though the groundstaff might still be finishing minor boundary rope adjustments — the essentials are in place, but not every last detail.
Finding Elements and Interacting
Elements are located using the By class, which supports strategies like By.ID, By.NAME, By.CSS_SELECTOR, and By.XPATH (covered in depth in the locator strategies topic). Once find_element() returns a WebElement, you interact with it through methods like send_keys() to type text, click() to trigger a mouse click, and clear() to empty a field — each of these calls, under the hood, is another WebDriver command sent to the driver and executed as a native browser interaction, not a direct manipulation of the DOM.
Cricket analogy: find_element() followed by send_keys() or click() is like a fielder first identifying which ball is live in play, then executing the specific action — throw, catch, or stop — only after correctly locating it, never acting on the wrong ball.
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
driver = webdriver.Chrome()
try:
driver.get("https://www.wikipedia.org")
search_box = WebDriverWait(driver, 10).until(
EC.presence_of_element_located((By.ID, "searchInput"))
)
search_box.send_keys("Selenium (software)")
search_box.submit()
WebDriverWait(driver, 10).until(EC.title_contains("Selenium"))
assert "Selenium" in driver.title
print("Test passed. Page title:", driver.title)
finally:
driver.quit()WebDriverWait combined with expected_conditions is Selenium's recommended 'explicit wait' pattern — it polls for a condition (like an element becoming present) up to a timeout, instead of using a blind time.sleep(), which either wastes time waiting too long or fails intermittently when it doesn't wait long enough.
Reading Results and Cleaning Up
After interacting with the page, a real test asserts something meaningful — here, that the resulting title contains the expected text — rather than merely running without crashing. Finally, driver.quit() closes every window associated with the session and terminates the underlying browser and driver processes; driver.close() only closes the current window, which matters once a script has opened multiple tabs or windows and needs to end just one of them.
Cricket analogy: Asserting the actual page title rather than just 'it didn't crash' is like judging an innings by the runs actually scored on the board, not merely by the fact that the batter survived without being dismissed.
Forgetting to call driver.quit() — especially if a test throws an exception partway through — leaves the browser and driver processes running in the background. Over many test runs, especially in CI, this accumulates into dozens of zombie browser processes consuming memory; wrapping the driver lifecycle in a try/finally block (or a test framework's fixture teardown) prevents this.
- A first Selenium script exercises session creation, navigation, element location, interaction, and teardown.
- driver.get() waits for document.readyState, not for every asynchronous resource to finish loading.
- By.ID, By.CSS_SELECTOR, and By.XPATH are common strategies passed to find_element().
- WebDriverWait with expected_conditions is the recommended explicit-wait pattern over time.sleep().
- A real test asserts a specific expected outcome, not just that the script ran without crashing.
- driver.quit() ends the whole session and browser process; driver.close() closes only the current window.
- Wrapping driver usage in try/finally prevents orphaned browser processes on test failure.
Practice what you learned
1. What does driver.get() wait for before returning?
2. What is the recommended alternative to time.sleep() for waiting on dynamic content?
3. What is the difference between driver.quit() and driver.close()?
4. Why should driver interactions be wrapped in a try/finally block?
5. Which class provides strategies like ID, CSS_SELECTOR, and XPATH for locating elements?
Was this page helpful?
You May Also Like
Installing Selenium and Browser Drivers
A practical walkthrough of installing the Selenium library and setting up matching browser drivers, including Selenium Manager's automatic driver handling.
Locator Strategies (ID, CSS, XPath)
How to choose and write reliable Selenium locators using ID, CSS selectors, and XPath, and how to weigh their tradeoffs.
Selenium WebDriver Architecture
How Selenium WebDriver's client-server architecture routes commands from your test script to the browser using the W3C protocol.