Selenium Quick Reference
This reference condenses the WebDriver API surface used in day-to-day Selenium work: locator strategies, wait patterns, common element and browser actions, and driver lifecycle commands. It's meant as a fast lookup for syntax you already understand conceptually, not a tutorial — pair it with the best-practices and framework guides for the reasoning behind why each pattern is used the way it is.
Cricket analogy: A quick reference is like a fielding chart pinned to the dugout wall — not a coaching manual explaining the theory, just the fast lookup a captain glances at mid-match to confirm a position.
Locators Cheat Sheet
By.ID is the fastest and most stable locator when a unique id exists; By.CSS_SELECTOR is the recommended default for everything else, supporting attribute matches (input[data-testid='x']), descendant combinators, and pseudo-classes (:nth-child, :not()); By.XPATH is reserved for cases CSS can't express, most commonly text-based matching (//button[contains(text(),'Submit')]) or traversing upward to a parent (//span[text()='Error']/ancestor::div[@class='alert']); By.LINK_TEXT and By.PARTIAL_LINK_TEXT locate anchor tags by their visible text; By.TAG_NAME and By.CLASS_NAME round out the list but are rarely precise enough to use alone on real applications.
Cricket analogy: Choosing By.ID first, falling back to CSS, and reserving XPath for last is like a captain's fielding priority: put your best fielder at the most likely catching position first, and only use a specialist substitution when nothing standard covers the gap.
# Locator cheat sheet
driver.find_element(By.ID, "email")
driver.find_element(By.CSS_SELECTOR, "input[data-testid='email']")
driver.find_element(By.CSS_SELECTOR, "ul.results li:nth-child(2)")
driver.find_element(By.XPATH, "//button[contains(text(),'Submit')]")
driver.find_element(By.XPATH, "//span[text()='Error']/ancestor::div[@class='alert']")
driver.find_element(By.LINK_TEXT, "Forgot password?")
driver.find_elements(By.CLASS_NAME, "product-card") # never throws; returns []
Waits and Actions Cheat Sheet
WebDriverWait(driver, timeout).until(EC.condition) is the standard synchronization pattern; common conditions include presence_of_element_located (in DOM, may not be visible), visibility_of_element_located (in DOM and rendered with non-zero size), element_to_be_clickable (visible and enabled), and staleness_of (waits for an element to be detached, useful after a page transition). ActionChains handles interactions the basic API can't, such as hover (move_to_element), drag-and-drop (drag_and_drop), and keyboard combos (key_down/key_up for modifier keys like Shift or Ctrl held during a click).
Cricket analogy: presence_of_element_located versus visibility_of_element_located is like a player being named in the squad list (present) versus actually walking out onto the field to bat (visible and ready to play).
WebDriver Setup and Common Commands
Standard lifecycle: instantiate a driver (webdriver.Chrome(), webdriver.Firefox()), navigate with driver.get(url), interact with elements (send_keys, click, clear, get_attribute, text), manage windows/tabs (driver.window_handles, driver.switch_to.window(handle)), handle frames (driver.switch_to.frame(name_or_id_or_element), driver.switch_to.default_content()), and always terminate with driver.quit() in a finally block or test fixture teardown to avoid orphaned browser processes accumulating on CI agents.
Cricket analogy: Always calling driver.quit() in a teardown is like a team always ensuring the ground is properly cleared and covered after every match, regardless of the result, so the venue is ready for the next game.
Keep this page bookmarked alongside the framework and best-practices guides — it covers syntax, not the reasoning for when to use WebDriverWait versus ActionChains, or why id beats XPath, which those guides explain in depth.
- Locator priority: By.ID > By.CSS_SELECTOR > By.XPATH (reserved for text-based or ancestor traversal needs).
- Standard wait pattern: WebDriverWait(driver, timeout).until(EC.condition_name(locator)).
- presence_of_element_located checks DOM presence only; visibility_of_element_located also requires rendering.
- element_to_be_clickable requires both visibility and an enabled state.
- ActionChains covers hover, drag-and-drop, and held-modifier-key interactions the basic API can't.
- Always terminate sessions with driver.quit() in a finally block or fixture teardown.
- switch_to.frame()/default_content() and switch_to.window(handle) manage frame and window/tab context explicitly.
Practice what you learned
1. Which locator should generally be tried first when a unique identifier exists?
2. What does visibility_of_element_located check that presence_of_element_located does not?
3. Which class handles interactions like hover and drag-and-drop that the basic WebElement API cannot?
4. What is the risk of forgetting to call driver.quit() in a test teardown?
5. What must you call to return WebDriver's focus to the main document after working inside an iframe?
Was this page helpful?
You May Also Like
Selenium Best Practices
Practical habits — stable locators, explicit waits, Page Object Model, and isolated test data — that turn a flaky Selenium suite into a dependable one.
Building an Automation Framework from Scratch
A practical blueprint for structuring a Selenium test automation framework — page objects, driver management, reporting, and parallel execution — from the ground up.
Selenium Interview Questions
The most commonly asked Selenium interview questions, from core WebDriver concepts to framework design judgment, with scenario-grounded answers.