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) Email confirmation is a critical part of most registration flows — account activation, password reset, multi-factor authentication, and onboarding. Every automation engineer eventually faces the same challenge: How do you verify an email confirmation link inside a Selenium test without making it slow and flaky? The wrong instinct is to automate Gmail's UI with Selenium. It's fragile, slow, and breaks constantly. The right approach: Use Selenium for browser automation Use JavaMail (IMAP) to read the email directly Extract the confirmation link Continue the test in Selenium Why Not Automate Gmail UI With Selenium? Automating the Gmail UI means logging in, searching, clicking a message, and parsing content from a third-party interface that changes frequently. This leads to: Flaky...
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"...