Verify Element Present & waitFor Command in Selenium
Krishna Rungta
⚡ Smart Summary
Verify element present and waitFor commands in Selenium IDE confirm that a page contains the elements and text a test expects, and pause playback until a dynamic condition becomes true before the next step runs.
A recorded Selenium IDE script clicks and types, but on its own it never decides whether the application behaved correctly. Two command families do that work: verify commands, which check the state of the page, and wait commands, which hold execution until the page is ready to be checked.
⚠️ A note on versions: the screenshots below come from the original Firefox-plugin Selenium IDE, which is no longer distributed, and they use its camelCase Selenese names. The current IDE is a Chrome, Firefox and Edge browser extension. The behaviour described here still applies, but several command names changed — a mapping table appears later in this article, and every original command and screenshot is preserved exactly as published.
Verify Presence of an Element
We can use following two commands to verify the presence of an element:
- verifyElementPresent – returns TRUE if the specified element was FOUND in the page; FALSE if otherwise
- verifyElementNotPresent – returns TRUE if the specified element was NOT FOUND anywhere in the page; FALSE if it is present.
Both commands take an element locator in the Target field — an id, a name, a CSS selector, a link text or an XPath expression — and neither needs a value.
The test script below verifies that the UserName text box is present within the Mercury Tours homepage while the First Name text box is not. The First Name text box is actually an element present in the Registration page of Mercury Tours, not in the homepage.
Because these are verify commands rather than assert commands, a failure is written to the log and the remaining steps still run. That distinction is covered in detail further down.
Verify Presence of a Certain Text in Command in Selenium
Checking that an element exists is not always enough — a test often needs to confirm the words shown to the user. Two text commands cover that case.
- verifyTextPresent – returns TRUE if the specified text string was FOUND somewhere in the page; FALSE if otherwise
- verifyTextNotPresent – returns TRUE if the specified text string was NOT FOUND anywhere in the page; FALSE if it was found
Remember that these commands are case-sensitive.
The log below shows the same page checked twice with two spellings of the same phrase.
In the scenario above, “Atlanta to Las Vegas” was treated differently from “atlanta to Las Vegas” because the letter “A” of “Atlanta” was in uppercase on the first one while lowercase on the other. When the verifyTextPresent command was used on each of them, one passed while the other failed.
Verify Specific Position of an Element
Layout defects rarely break a locator, so presence checks miss them. Position commands close that gap.
Selenium IDE indicates the position of an element by measuring (in pixels) how far it is from the left or top edge of the browser window.
- verifyElementPositionLeft – verifies if the specified number of pixels match the distance of the element from the left edge of the page. This will return FALSE if the value specified does not match the distance from the left edge.
- verifyElementPositionTop – verifies if the specified number of pixels match the distance of the element from the top edge of the page. This will return FALSE if the value specified does not match the distance from the top edge.
The script below records the expected pixel offsets in the Value column.
Treat these two commands with care. A pixel offset changes with the window size, the zoom level and the installed fonts, so a hard-coded number that passes on one machine can fail on another.
Wait Commands in Selenium
A verify command can only inspect what is already on screen, so a check that runs too early fails even though the application is working. Wait commands solve that timing problem.
The following are the types of wait commands in Selenium
andWait commands
These are commands that will wait for a new page to load before moving onto the next command.
Examples are
- clickAndWait
- typeAndWait
- selectAndWait
Every one of them is an ordinary action command with the AndWait suffix attached, as the recorded step below shows.
waitFor commands
These are commands that wait for a specified condition to become true before proceeding to the next command (irrespective of loading of a new page). These commands are more appropriate to be used on AJAX-based dynamic websites that change values and elements without reloading the whole page. Examples include:
- waitForTitle
- waitForTextPresent
- waitForAlert
Consider the Facebook scenario below.
We can use a combination of “click” and “waitForTextPresent” to verify the presence of the text “Providing your birthday.”
We cannot use clickAndWait because no page was loaded upon clicking on the “Why do I need to provide my birthday?” link. If we do, the test will fail
The same rule applies to any content injected by script rather than by navigation, which is why AJAX-driven screens almost always need waitFor rather than andWait.
Assert vs Verify vs waitFor Commands in Selenium IDE
Beginners frequently pick the wrong family and then wonder why a suite stops on the first defect, or why it reports twenty failures that all trace back to one. The three prefixes answer three different questions.
| Prefix | What it does | On failure | Best used for |
|---|---|---|---|
| assert | Checks a condition immediately | Logs the failure and stops the test case | Preconditions — a login that must succeed before anything else makes sense |
| verify | Checks a condition immediately | Logs the failure and continues with the next command | Independent checks, such as several labels on one confirmation page |
| waitFor | Polls until the condition becomes true | Logs the failure once the timeout expires, then continues | Anything that appears late — AJAX responses, spinners, dialogs |
A practical pattern combines all three: assert the page you landed on, waitFor the element that arrives asynchronously, then verify each individual field. Doing it in that order means one broken navigation stops the test early, while a handful of cosmetic mismatches are all reported in a single run. The same discipline carries over to Selenium tests written in code, where the equivalents are hard assertions, soft assertions and explicit waits.
Verify and Wait Commands in the Current Selenium IDE
The Firefox-plugin IDE that produced the screenshots above was retired, and the command set was rebuilt for the current browser extension. Several Selenese names survived, some were renamed, and a few were dropped. The table below maps the commands used in this article to their present-day equivalents, taken from the official Selenium IDE command reference.
| Legacy Selenese command | Command in the current IDE |
|---|---|
| verifyElementPresent | verify element present |
| verifyElementNotPresent | verify element not present |
| verifyTextPresent | verify text (scoped to an element locator, not the whole page) |
| verifyTextNotPresent | verify not text (scoped to an element locator) |
| verifyTitle | verify title |
| verifyElementPositionLeft / verifyElementPositionTop | No equivalent — position assertions were dropped |
| clickAndWait, typeAndWait, selectAndWait | No AndWait suffix — the open command already waits for a page load |
| waitForElementPresent | wait for element present, with a wait time in milliseconds |
| waitForAlert | assert alert or verify alert text after the dialog appears |
Two differences matter most in day-to-day work. First, the current wait commands — wait for element present, wait for element visible, wait for element editable and their negative twins — each take an explicit wait time in milliseconds, so a slow step no longer has to share one global timeout. Second, the page-wide text search is gone: verify text needs a locator, which usually produces a sharper check anyway.
Common Errors with Verify and waitFor Commands
Most reported problems with these commands are not defects in the IDE. The list below covers the failures that come up most often and what fixes each one.
- The element exists but the check still fails. Presence and visibility are different states. An element hidden behind a CSS rule is still present in the DOM, so pair the presence check with wait for element visible when the test depends on the user actually seeing it.
- A text check fails on wording that looks identical. Non-breaking spaces, trailing whitespace and curly apostrophes copied from a design document all break an exact match. Retype the expected string by hand rather than pasting it.
- A wait command times out on a page that clearly loaded. The element is usually inside an iframe. Run select frame first, otherwise the locator is evaluated against the wrong document.
- clickAndWait hangs on a single-page application. No navigation happens, so there is nothing to wait for. Replace it with a click plus the appropriate waitFor command.
- A position check passes locally and fails on the build server. Screen size and font rendering differ. Prefer a presence or text check, or set an explicit window size at the start of the test.
- The whole suite stops at the first mismatch. An assert command was recorded where a verify command was intended. Switch the prefix and the run will report every failure instead of just the first.
Once a script survives these traps, the next step is usually to store runtime values in variables so the checks compare against real data rather than hard-coded strings.
