101 posts tagged with "Test Automation"

The test still passes. The alert never renders.Direct link to The test still passes. The alert never renders.

Your team migrated a patient medication dashboard to Next.js App Router. You refactored MedicationList as a Server Component to cut Time to First Byte. You wrapped DrugInteractionAlert in a <Suspense> boundary so the medication list appears immediately while the interaction check runs in parallel. Perceived performance improved.

CI stayed green. Your Playwright suite passed every run.

Two weeks later, a nurse filed a bug report: the drug interaction banner wasn't showing on slow hospital wifi connections. It would flash briefly and disappear, or sometimes never appear at all. The medications rendered. The alert — the one that warns about a contraindicated combination — didn't.

The test wasn't catching it because the test was using waitForLoadState('networkidle'). By the time Playwright declared the page idle, the medication list had streamed in and the interaction check was still in-flight. The test asserted the page, saw no alert, logged a pass.

This is not a hypothetical failure mode. It is a specific class of bug introduced by migrating to App Router without updating your test assumptions — and it is consequential in proportion to how much your UI surfaces clinically relevant information.

This post covers what App Router actually changed in the rendering model, why it breaks existing test suites in ways that are especially dangerous for health-adjacent applications, and how O2 — DevAssure's PR-native testing agent — handles these rendering patterns natively without requiring you to write or maintain a single test script.

Last month I had a conversation with a CTO that stuck with me.

Their team has 3,400 tests. 94% coverage. A CI pipeline that runs on every PR. Tests pass reliably — less than 2% flaky rate. By every industry metric, this is a well-tested codebase.

They also had 6 production bugs in the past 30 days. All reported by users. All missed by the test suite.

I asked him to send me the bugs. Here's what they were:

1. A modal didn't close when clicking outside it. Users had to refresh the page to dismiss a confirmation dialog.
2. A price displayed as $1,299 in the cart but charged $12.99. Decimal formatting inconsistency between the display component and the payment API.
3. The "Export to CSV" button worked on Chrome, broke on Safari. Downloaded an empty file.
4. A newly added field was editable for admins but displayed as read-only for regular users — the opposite of what it should have been. Permission logic was inverted.
5. A search that returned 0 results showed the previous results instead of an empty state. Stale state from a React component not resetting.
6. The onboarding flow skipped step 3 entirely when the user's timezone was UTC+0. A conditional that checked for a truthy timezone value — and 0 is falsy in JavaScript.

None of these are exotic edge cases. Every one of them is something a human using the app would hit within 5 minutes.

And none of them were caught by 3,400 tests at 94% coverage.

Why?

At Microsoft Build 2026, Microsoft announced something that quietly confirms the core thesis behind DevAssure: as AI agents take over more of the software development lifecycle, the agent that writes the code cannot be the agent that grades the code.

The announcement was a pair of open-source projects — ASSERT (Adaptive Spec-driven Scoring for Evaluation and Regression Testing) and the Agent Control Specification (ACS) — designed to give developers a portable, framework-agnostic way to evaluate and govern AI agents before their behavior ships to production. Coming from the company now positioning itself as the "agent-first" platform for enterprise development, this is a meaningful signal about where the industry is heading.

I want to walk through what Microsoft actually shipped, why it matters beyond agent safety, and what it means for teams where 30–40% of code is already AI-generated — because the validation gap Microsoft just named at the agent layer is the same gap most engineering teams still have at the application layer.

Flutter is popular for building cross-platform applications from a single codebase. The same Dart code can target Android, iOS, desktop, and the web. But when it comes to end-to-end testing Flutter web apps, teams often hit a frustrating problem:

"Why can't Selenium or Playwright see my buttons, text fields, dropdowns, and labels?"

The short answer: many Flutter web apps render the UI into a canvas instead of exposing normal HTML elements. That changes how testing needs to be approached.

This post explains how Flutter web works internally, why the DOM is often not useful for automation, and practical options for testing — including how the DevAssure O2 agent unlocks the Flutter DOM for element-level automation and applies visual reasoning over the canvas when selectors are unavailable. If you are new to canvas automation, start with our guides on canvas test automation and Flutter web automation without image-based hacks.

Every Salesforce team tests. The question is how — and what slips through the cracks depending on which approach you use.

In this post, I'm going to take a real Salesforce application — Dreamhouse, Salesforce's official sample app — and test the same functionality three different ways:

1. Apex unit tests (the traditional Salesforce-native approach)
2. Selenium WebDriver (the industry-standard UI automation approach)
3. DevAssure O2 Agent (autonomous browser-based testing)

For each approach, I'll show you the actual code, explain what it catches, what it misses, and the ongoing maintenance cost. By the end, you'll have a clear picture of where each approach fits — and where it falls short.

For years, I led teams focused on engineering productivity and release management across startups and enterprises. My primary job was not just shipping features — it was ensuring release trains moved predictably, developers remained productive, and quality gates did not become velocity killers.

One thing became very clear over time:

Engineering velocity was rarely limited by coding speed. It was limited by testing friction.

You merged on Friday. Checkout looked fine in the diff. By Monday, support tickets say promo codes stop applying after a failed payment retry.

The PR was 400 lines, mostly written by Cursor in an afternoon. Two approvals. Green CI — because unit tests passed and nobody had an E2E check for that path.

Every team wants E2E tests on every PR. Almost none actually has them — because someone has to write those tests, fix them when the UI changes, and defend a thirty-minute CI job that still flakes.

If you are the developer opening the PR, that someone is often you, after hours, clicking re-run on a red check you do not trust.

Your team already plans and tracks tests in TestRail. The gap is execution: turning those cases into reliable UI automation without a second script suite to maintain. DevAssure closes that loop—fetch cases from TestRail, run them in a real browser with an AI agent, and optionally sync results, defects, and videos back to TestRail.

Every TestRail workflow in this guide is available in two places: the @devassure/cli for terminals and CI/CD, and the DevAssure VS Code extension (VSCE) for interactive runs from the IDE. Configure once—credentials and post-result settings are shared between both.