Skip to main content

Posts

Verify email confirmation using Selenium WebDriver

Note: If you are new to java and selenium then start with selenium java training videos .     How to Verify Email Confirmation Using Selenium 4 and JavaMail (2026 Guide) Updated: 2026 (Original article published August 02, 2011) Email confirmation is an integral part of most registration flows — account activation, password reset, multi-factor authentication, and onboarding emails. Sooner or later, every automation engineer faces the same challenge: How do we verify an email confirmation link inside a Selenium test without making the test slow and flaky? Many beginners try to automate Gmail UI using Selenium. That approach is fragile, slow, and tightly coupled to a third-party UI that changes frequently. A cleaner approach is this: Use Selenium for browser automation. Use JavaMail (IMAP) to read the email directly. Extract the confirmation link. Continue the test using Selenium. This guide shows a modern, production-ready approach using Selenium 4 and JavaMail . Why Not Auto...
Recent posts

The Silent Killer of Test Automation: False Confidence

 Most automation suites don’t fail loudly. They fail silently. Green build. 100% tests passed. Pipeline successful. And production still breaks. That is the silent killer of test automation: false confidence . Let’s talk about why it happens — and how to prevent it. 1. Passing Tests That Don’t Test Anything This is more common than we admit. Examples: Assertions that check only page titles Tests that don’t verify business outcomes Mock-heavy tests that ignore real integrations UI tests that only validate element presence, not behavior If your test doesn’t fail when the feature breaks, it is not a test — it is decoration. Ask yourself: If I intentionally break this feature, will this test catch it? If the answer is “maybe”… it won’t. 2. Over-Reliance on UI Automation UI automation (Selenium, Playwright, Cypress) is powerful — but fragile. Common mistake: Testing everything through the UI Ignoring API-level verification Treating end-to-end tests as the main safety net UI tests should...

Which location strategy to use with mobile apps

Locator Strategy for native mobile apps IDs and accessibility locators are still king. NSPredicate (iOS) and UIAutomator (Android) are great—mainly better than XPath —but they do not beat a good accessibility id or resource-id . And CSS selectors don’t exist for native apps (only for WebViews). Locator Strategy Ranking Rank iOS (native) Android (native) Why 1 Accessibility ID → name / label (via MobileBy.AccessibilityId or @iOSXCUITFindBy(accessibility = "Mehr anzeigen") ) Accessibility ID → content-desc (via MobileBy.AccessibilityId ) or @AndroidFindBy(accessibility = "Letzte Aktivitäten, Überschrift") ) Fast, readable, stable when set intentionally; improves a11y. 2 Stable identifiers (rare on iOS) resource-id (via new UiSelector().resourceId(...) ) or @AndroidFindBy(id = "load_more") id is just shorthand for matching the native Android resource-id attribute. Appium automatically maps id → resource-id If you pass only "load_more"...