Element Present & waitFor Komutunu Doğrulayın Selenium
Krishna Rungta
⚡ Akıllı Özet
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.
Kaydedilmiş bir Selenium IDE script clicks and types, but on its own it never decides whether the application behaved correctly. Two command families do that work: doğrulamak commands, which check the state of the page, and beklemek commands, which hold execution until the page is ready to be checked.
⚠️ Sürümlerle ilgili bir not: Aşağıdaki ekran görüntüleri orijinalinden alınmıştır. Firefox-Eklenti Selenium IDE, which is no longer distributed, and they use its camelCase Selenese names. The current IDE is a Chrome, Firefox ve Edge tarayıcı uzantısı. 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.
Bir Öğenin Varlığını Doğrulayın
Bir elemanın varlığını doğrulamak için aşağıdaki iki komutu kullanabiliriz:
- doğrulamaElementPresent – belirtilen öğe sayfada BULUNDUYSA TRUE; aksi takdirde FALSE döndürür
- doğrulamaElementNotPresent – belirtilen öğe sayfanın herhangi bir yerinde BULUNAMADIYSA DOĞRU değerini döndürür; Eğer varsa YANLIŞ.
Both commands take an element lokasyon içinde Target field — an id, a name, a CSS selector, a link text or an XPath expression — and neither needs a value.
Aşağıdaki test betiği, KullanıcıAdı metin kutusunun mevcut olduğunu doğrular. Mercury Tur anasayfası, Ad metin kutusu ise yok. Ad metin kutusu aslında Kayıt sayfasında bulunan bir öğedir. Mercury Turlar, ana sayfada değil.
Çünkü bunlar doğrulamak commands rather than ileri sürmek commands, a failure is written to the log and the remaining steps still run. That distinction is covered in detail further down.
Komutta Belirli Bir Metnin Varlığını Doğrulayın 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.
- doğrulamaTextPresent – belirtilen metin dizesi sayfada bir yerde BULUNDUYSA TRUE döndürür; aksi takdirde FALSE döndürür
- doğrulamaTextNotPresent – belirtilen metin dizesi sayfanın herhangi bir yerinde BULUNAMADIYSA DOĞRU değerini döndürür; Bulunduysa YANLIŞ
Bu komutların büyük/küçük harfe duyarlı olduğunu unutmayın.
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.
Bir Elemanın Özel Konumunu Doğrulayın
Layout defects rarely break a locator, so presence checks miss them. Position commands close that gap.
Selenium IDE, bir öğenin konumunu, tarayıcı penceresinin sol veya üst kenarından ne kadar uzakta olduğunu ölçerek (piksel cinsinden) belirtir.
- doğrulamaElementPositionLeft – belirtilen piksel sayısının, öğenin sayfanın sol kenarından uzaklığıyla eşleşip eşleşmediğini doğrular. Belirtilen değer sol kenardan olan mesafeyle eşleşmiyorsa bu, FALSE değerini döndürür.
- doğrulamaElementPositionTop – belirtilen piksel sayısının, öğenin sayfanın üst kenarından uzaklığıyla eşleşip eşleşmediğini doğrular. Belirtilen değer üst kenardan olan mesafeyle eşleşmiyorsa bu, FALSE değerini döndürür.
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.
Komutları Bekle 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.
Aşağıda, bekleme komutlarının türleri verilmiştir: Selenium
veBekle komutları
Bunlar bir sonraki komuta geçmeden önce yeni bir sayfanın yüklenmesini bekleyecek komutlardır.
Örnekler
- tıklayınvebekleyin
- yazınVeBekle
- seçvebekle
Every one of them is an ordinary action command with the AndWait suffix attached, as the recorded step below shows.
komutları bekle
Bunlar, bir sonraki komuta geçmeden önce (yeni bir sayfanın yüklenmesinden bağımsız olarak) belirli bir koşulun gerçekleşmesini bekleyen komutlardır. Bu komutların, tüm sayfayı yeniden yüklemeden değerleri ve öğeleri değiştiren AJAX tabanlı dinamik web sitelerinde kullanılması daha uygundur. Örnekler şunları içerir:
- waitForTitle
- waitForTextPresent
- waitForAlert
Aşağıdaki Facebook senaryosunu düşünün.
"Doğum gününüz sağlanıyor" metninin varlığını doğrulamak için "tıklayın" ve "waitForTextPresent" kombinasyonunu kullanabiliriz.
“Doğum günümü neden belirtmem gerekiyor?” tıklandığında hiçbir sayfa yüklenmediğinden clickAndWait'i kullanamıyoruz. bağlantı. Bunu yaparsak test başarısız olur
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.
| Önek | Ne yapar | On failure | En iyi kullanım için |
|---|---|---|---|
| ileri sürmek | Checks a condition immediately | Logs the failure and stops the test case | Preconditions — a login that must succeed before anything else makes sense |
| doğrulamak | Checks a condition immediately | Logs the failure and continues with the next command | Independent checks, such as several labels on one confirmation page |
| bekle | 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
MKS 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 |
|---|---|
| doğrulamaElementPresent | verify element present |
| doğrulamaElementNotPresent | verify element not present |
| doğrulamaTextPresent | verify text (scoped to an element locator, not the whole page) |
| doğrulamaTextNotPresent | 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.
