Testing
EarlGrey's interaction API covers the full range of touch gestures and UI interactions available on iOS. Every interaction runs after EarlGrey confirms the app is idle and the target element is visible and hittable. Basic Interactions Tap // Single tap EarlGrey.selectElement(with: grey_accessibilityID("submitButton")) .perform(
Testing
EarlGrey tests run with xcodebuild test like any XCTest suite. The challenge is iOS simulator availability, macOS runner requirements, and collecting test artifacts from CI. Prerequisites EarlGrey requires: * macOS runner (not Linux — iOS simulators only run on macOS) * Xcode installed * An iOS simulator available GitHub Actions Basic Setup # .github/workflows/
Testing
Selenide is built on Selenium WebDriver. Every Selenide test ultimately calls Selenium under the hood. But the developer experience is so different that teams often switch without fully understanding what changed. This post covers the concrete differences. The Core Problem Selenide Solves Selenium gives you a raw browser automation API.
Testing
End-to-end tests for micro-frontends are harder to set up than for monolithic apps, but they're not optional. Unit tests and contract tests verify pieces in isolation. E2E tests verify that everything works together when a real user navigates through the composed application — crossing remote boundaries,
Testing
Once you're past the basics of Selenide, you'll hit scenarios where simple CSS selectors aren't enough: dynamic content, nested components, shadow DOM, iframes, and complex page structures. Here's how to handle them, plus how to organize tests with page objects. Selector Reference
Testing
Selenide is a Java framework built on top of Selenium WebDriver that removes the boilerplate. No more WebDriverWait, no manual driver downloads, no Thread.sleep() calls scattered through your tests. You write what the test should do, and Selenide handles the plumbing. Why Selenide Over Raw Selenium Raw Selenium gives
Testing
Selenide's assertion API is what makes it worth using over raw Selenium. The fluent should / shouldHave / shouldBe methods combine waiting and assertion into a single call, with failure messages that tell you what actually happened. Core Assertion Methods Every SelenideElement exposes three assertion methods: Method Use for shouldBe(
Testing
Security controls fail silently. A broken authentication check doesn't throw an exception—it returns 200 where it should return 403. A rate limiter with an off-by-one error doesn't log a warning—it just lets the attack through. And because security failures are often hard
Security Testing
A security testing plan documents what security testing you'll do, when, how, and with what tools. Without a plan, security testing is ad hoc—some things get tested, others don't, and nobody knows what was actually covered. A good plan defines scope, testing types for each
Security Testing
Dynamic analysis means analyzing software by executing it. DAST—sending HTTP attack probes to a running application—is the most common form, but it's just one technique. Dynamic analysis also includes: taint analysis (tracking how data flows at runtime), concolic testing (symbolic execution combined with real execution), memory
Testing
Security regression testing is the practice of continuously verifying that security controls remain effective as codebases evolve. It's the discipline that prevents a passing security audit in January from becoming a failed one in December. Without it, every feature deployment is a potential compliance event — and you won&
API Testing
API documentation that lies is worse than no documentation. When a spec says an endpoint returns { "id": "string" } but the server actually returns { "id": 42 }, every consumer who read the docs gets a runtime surprise. Dredd is a tool specifically built to prevent this.