realistic-mode

name

realistic-mode

description

Use Biloba's realistic interaction track (b.Realistic()) when a spec must exercise the realism the fast default trades away — clicking through/around an occluding overlay, a menu that opens on CSS :hover, scroll-into-view, a pointer drag (@dnd-kit/Sortable), real wheel scrolling, or touch. Covers what each interaction track actually does (the fast-vs-realistic capability matrix), the inline/per-spec/per-suite (Label) patterns, when NOT to use it, and BeClickable() as a cheaper occlusion guard. Use when testing occlusion/hover/drag/scroll-sensitive flows or deciding fast vs realistic.

Realistic interactions

Two interaction tracks on the same tab:

• Fast track (default b) — atomic JS simulations: a click is element.click() after synchronous visibility/enabled checks. No scroll, no occlusion test, no real :hover. What you want for the bulk of specs.
• Realistic track (b.Realistic()) — a *Biloba view of the same tab whose interactions run through real Chrome DevTools Protocol input. The default b is untouched.

rb := b.Realistic()
rb.Click("#submit")                     // scrolls into view, waits for stability, refuses to click through an overlay, real mouse click
Eventually(".menu").Should(rb.Hover())  // moves the real pointer → CSS :hover activates

Docs: https://onsi.github.io/biloba/#realistic-interactions.

When to reach for it

Quarantine it to a handful of smoke tests. It costs real round-trips and can reintroduce the timing flake the atomic model avoids — that's the deliberate, opt-in cost.