onsi
- 43 skills
- 0 followers
- 18 hours ago last updated
- ▌ Setup 2 · onsiWire Biloba's TypeScript client into Vitest — install biloba and its platform package, install chrome-headless-shell, start one shared Chrome in global setup, provide its connection to workers, create one daemon and reusable root Session per test file, prepare between tests, close cleanly, and choose launch modes/options. Use when installing biloba or changing suite-level browser/daemon lifecycle.
- ▌ Overview 2 · onsiExplain Biloba's TypeScript/Vitest mental model — one shared Chrome, one bilobad process per Vitest worker, isolated reusable root sessions, server-side polling, fast versus realistic input, and structured diagnostics. Use first when adopting biloba or deciding how to structure a Vitest browser suite. Route to the other biloba-vitest:* skills.
- ▌ Flake Hunt 2 · onsiRun a flake hunt on a Biloba Vitest suite — run the whole browser suite many times (60 by default), every run to completion with its own JSON report, then read each test's failure rate, the seeds, and the failure evidence out of those reports instead of re-running. Covers the hunt script (vitest run with shuffle and a recorded seed, maxWorkers at the measured knee, no retry or bail, a per-run BILOBA_SCREENSHOTS_DIR, and the seed, wall clock, and exit status the JSON reporter doesn't record), the runs the JSON reports as clean when they aren't (unhandled errors, failed beforeAll hooks, killed runs), logging BilobaError's code and trajectory, what keeps a hunt a valid measurement (one hunt at a time on an idle machine, nothing editing the tree, focused hunts for iterating only, stale visual baselines), how many clean runs it takes to call a flake dead, reading the results (one systemic race behind many names, stalled tabs, a long tail that clusters by run), and the performance record a hunt produces (test timin
- ▌ Write Tests 2 · onsiAuthor Biloba browser tests in TypeScript/Vitest — sessions, tabs, frames, CSS/semantic/XPath locators, polling actions and assertions, realistic input, cookies/storage, dialogs/downloads/network, screenshots, and structured failures. Use when writing or reviewing tests against biloba. For wiring the daemon and shared Chrome, use biloba-vitest:setup.
- ▌ Debug Failures 2 · onsiDiagnose Biloba failures in TypeScript/Vitest — BilobaError codes and fields, polling trajectories, DOM outlines, screenshots and visual artifacts, context-wide session.captureDiagnostics(), console/warning streams, debug logs, Vitest hooks, and renderer/browser/daemon crash distinctions. Use when a Biloba Vitest test fails, hangs, flakes, or needs CI/agent artifact configuration.
- ▌ Visual Assertions 2 · onsiCreate and maintain Biloba screenshot assertions in TypeScript/Vitest — page and locator captures, committed baselines, update mode, masks, pixel and channel tolerances, animation freezing, light/dark schemes, diff artifacts, and structured visual diagnosis. Use when adding expectScreenshot(), reviewing baselines, or diagnosing a visual mismatch.
- ▌ Async · onsiPolling assertions in Gomega — Eventually (poll until it passes) and Consistently (must keep passing), the func(g Gomega) callback idiom, WithTimeout/WithPolling/Within/ProbeEvery, WithContext and Ginkgo SpecContext, StopTrying/TryAgainAfter bail-outs, MustPassRepeatedly, and default-interval tuning. Use when an assertion can't be true synchronously — anything involving goroutines, channels, network calls, eventual consistency, or "wait until / stays true".
- ▌ Gexec · onsiTesting external processes with gexec — compile binaries with Build/BuildWithEnvironment/BuildIn and CleanupBuildArtifacts, start them with Start returning a *Session, await exit with the Exit matcher (Eventually(session).Should(Exit(0))), Wait/ExitCode, signal via Kill/Terminate/Interrupt/Signal and package-level KillAndWait/TerminateAndWait, and assert on session.Out/Err which are gbytes buffers (Say, Contents). Use when building, running, signaling, or asserting on subprocesses in Go tests.
- ▌ Ghttp · onsiThe ghttp test HTTP server for testing HTTP clients — NewServer/NewTLSServer, AppendHandlers, the Verify* assertions (VerifyRequest/VerifyHeader/VerifyHeaderKV/VerifyJSON/VerifyForm/VerifyBasicAuth/VerifyContentType/VerifyBody), RespondWith/RespondWithJSONEncoded(Ptr), CombineHandlers, RouteToHandler for unordered MUXed routes, AllowUnhandledRequests, RoundTripper, and TLS. Use when testing code that makes outbound HTTP requests.
- ▌ Gleak · onsigleak goroutine leak detection — capture a Goroutines() snapshot before a test, then Eventually(Goroutines).ShouldNot(HaveLeaked(snapshot)) to assert none leaked, with the BeforeEach/AfterEach/DeferCleanup pattern, ignoring matchers IgnoringTopFunction/IgnoringInBacktrace/IgnoringGoroutines/IgnoringCreator, well-known non-leaky goroutines, goroutine IDs, ReportFilenameWithPath, and the Ginkgo -p IgnoreGinkgoParallelClient gotcha. Use when a test must verify goroutines started during the test have all wound down and nothing leaked.
- ▌ Gbytes · onsiTesting streaming io buffers with gbytes — gbytes.NewBuffer() (an io.Writer also returned by gexec sessions), the Say(regexp) matcher that forward-scans from a moving read cursor, the canonical Eventually(buffer).Should(Say(...)) streaming pattern, sequential cursor-advancing Say calls, Contents(), BufferWithBytes/BufferReader, buffer.Detect for branching, and TimeoutReader/Writer/Closer for testing blocking io.Reader/Writer/Closer. Use when asserting on streaming or incremental output (process stdout/stderr, API streams, io.Readers) rather than a complete value.
- ▌ Gstruct · onsiDeep, partial matching of nested structs, slices, maps, and pointers with gstruct — MatchAllFields/MatchFields/Fields, MatchAllElements/MatchElements/Elements (idFn), MatchAllKeys/MatchKeys/Keys, PointTo, and the IgnoreExtras/IgnoreMissing/IgnoreUnexportedExtras/AllowDuplicates options, plus Ignore()/Reject(). Use when asserting against large or deeply nested data structures where you want to apply a different matcher to each field, element, or key.
- ▌ Gmeasure · onsiBenchmark and measure Go code with gmeasure — an Experiment groups named Measurements, recorded via RecordValue/RecordDuration/MeasureDuration or repeated Sample/SampleValue/SampleDuration with SamplingConfig, timed inline with a Stopwatch, summarized through GetStats/Stats (StatMin/Max/Mean/Median/StdDev, ValueFor/DurationFor) and compared with RankStats; decorate output with Units/Precision/Style/Annotation, render in Ginkgo via AddReportEntry, and persist with ExperimentCache. Use when you need human-readable benchmarks, performance reports, or regression baselines (not pass/fail assertions on their own).
- ▌ Matchers · onsiThe complete catalog of Gomega's built-in matchers, grouped by category — equivalence (Equal/BeEquivalentTo/BeComparableTo/BeIdenticalTo/BeAssignableToTypeOf), presence (BeNil/BeZero/BeEmpty), truthiness (BeTrue/BeFalse/BeTrueBecause), errors (HaveOccurred/Succeed/MatchError), channels (Receive/BeClosed/BeSent), files, strings/JSON/XML/YAML, collections (ContainElement/ConsistOf/HaveExactElements/HaveKey), structs (HaveField), numbers/times (BeNumerically/BeTemporally), values (HaveValue), HTTP responses, and panics. Use when you need to find or choose the right matcher for an assertion instead of defaulting to Equal.
- ▌ Assertions · onsiWrite correct synchronous Gomega assertions — Expect/Ω notation, the To/NotTo/ToNot/Should/ShouldNot equivalences, the multi-return error idiom, Succeed vs HaveOccurred, the .Error() chaining form, annotating assertions (format-string and func()string), tuning failure output via the format subpackage (MaxLength/MaxDepth/UseStringerRepresentation/GomegaStringer/TruncatedDiff/RegisterCustomFormatter/format.Object), and asserting inside helper functions with GinkgoHelper/WithOffset/ExpectWithOffset, NewWithT(t) for plain testing, and the g Gomega callback. Use when writing or reviewing synchronous (non-polling) Gomega assertions.
- ▌ Custom Matchers · onsiWriting your own Gomega matchers — the GomegaMatcher interface (Match/FailureMessage/NegatedFailureMessage), gcustom.MakeMatcher with message templates and template data, the format package helpers (format.Message/format.Object), MatchMayChangeInTheFuture and StopTrying for Eventually/Consistently, and how to test and package custom matchers. Use when a built-in or composed matcher can't express your domain assertion and you need to build one.
- ▌ Composing Matchers · onsiBuild compound Gomega assertions by combining matchers — And/SatisfyAll (all pass), Or/SatisfyAny (any pass), Not (negate), WithTransform to map the actual before matching, Satisfy for an ad-hoc predicate, HaveValue to dereference pointers/interfaces, HaveField for struct fields and method results, HaveEach for every element, plus the matchers-as-arguments idiom that lets you nest matchers inside ContainElement/ConsistOf/HaveKeyWithValue/Receive. Use when one Expect needs several requirements at once, or you want to assert deep into a value without writing a custom matcher.
- ▌ CI · onsiConfigure Ginkgo for continuous integration — the recommended CLI flag set and the rationale for each flag (-r -p --randomize-all --randomize-suites --fail-on-pending --fail-on-empty --keep-going --cover --race --trace --json-report --timeout --poll-progress-after/-interval), invoking via go run to pin the CLI to go.mod, the exit-code safeguards that catch committed Focus/Pending and empty filters, collecting report and coverage artifacts with --output-dir, CI-friendly output (--github-output/--force-newlines/--no-color), and the fixed per-suite cost --race adds (GORACE=atexit_sleep_ms=0). Use when setting up or hardening a CI pipeline for a Ginkgo suite.
- ▌ Running · onsiRun Ginkgo suites with the ginkgo CLI — run, -r, -p, --dry-run, watch, build (precompiled .test binaries), generate, outline, unfocus, labels, version; spec randomization (--randomize-all/--randomize-suites/--seed); running multiple suites (--keep-going/--skip-package/--compilers); previewing (--dry-run, PreviewSpecs); and parameterizing a suite via env vars or init()-registered flags after -- plus GinkgoConfiguration() overrides. Use when running suites locally, precompiling, watching for changes, or parameterizing a run from the command line. For a CI configuration see ginkgo:ci.
- ▌ Filtering · onsiRun a subset of a Ginkgo suite — Pending/PIt/XIt, runtime Skip, programmatic Focus/FIt (and ginkgo unfocus), Label with the --label-filter query language and label sets, suite-level labels, SemVerConstraint/--sem-ver-filter, --focus/--skip and --focus-file/--skip-file, the filtering precedence rules, and --fail-on-pending/--fail-on-empty. Use when you want to run, skip, focus, label, or version-gate specs, or debug why specs were or weren't selected.
- ▌ Reporting · onsiGenerate, consume, and enrich Ginkgo reports — console verbosity (-v/-vv/--trace/--no-color/--succinct), machine-readable reports (--json-report/--junit-report with --output-dir/--keep-separate-reports), programmatic reporting nodes (ReportAfterEach, ReportAfterSuite, CurrentSpecReport), AddReportEntry with ReportEntryVisibility, and profiling (--cover/--race/--cpuprofile/--memprofile). Use when you need a report file, custom suite-level reporting, attaching data to a spec, controlling console output, or profiling a suite.
- ▌ Decorators · onsiOne-line reference for every Ginkgo decorator, grouped by what it does, with the node types each can decorate — Serial, Ordered, ContinueOnFailure, OncePerOrdered, Label, Focus, Pending, FlakeAttempts, MustPassRepeatedly, NodeTimeout, SpecTimeout, GracePeriod, PollProgressAfter/Interval, SuppressProgressReporting, SpecPriority, SemVerConstraint, AroundNode, Offset/CodeLocation, EntryDescription. Use to look up a decorator's exact name, semantics, and where it's legal.
- ▌ Parallelism · onsiRun Ginkgo suites in parallel — ginkgo -p / --procs, the separate-process (not goroutine) model, SynchronizedBeforeSuite/SynchronizedAfterSuite vs BeforeSuite, GinkgoParallelProcess() for sharding ports/tmpdirs/databases, building a binary once via gexec, piping child-process output to GinkgoWriter, and what N processes actually cost (compilation vs teardown, and the fixed ~1s --race adds per suite — GORACE=atexit_sleep_ms=0). Use when parallelizing a suite, speeding up integration tests, auditing why a parallel run is slow, fixing parallel-only flakes/races, sharding external resources, or choosing between BeforeSuite and SynchronizedBeforeSuite.
- ▌ Writing Specs · onsiAuthor good Ginkgo specs — container nodes (Describe/Context/When), subject nodes (It/Specify), setup/cleanup nodes (BeforeEach, JustBeforeEach, AfterEach, DeferCleanup, BeforeSuite/AfterSuite), the "declare in container, initialize in BeforeEach" rule, separating creation from configuration, reusable test helpers with GinkgoHelper()/GinkgoHelperGo(), and By/GinkgoWriter output. Use when writing or reviewing specs or extracting a test helper. Covers the tree-construction-time pitfalls (no assertions/init/loop-capture in container bodies).
- ▌ Debugging Failures · onsiDiagnose a failing Ginkgo suite as an agent — always run with --json-report into a predictable temp/gitignored location, read the terminal verdict line, then use jq to extract structured failure details (name, message, file:line, panic value, captured logs). Covers the panicked-vs-failed trap, panic locations pointing into the Go runtime, parallel output interleaving, reproducing with --seed, and progress reports for hangs. Use when a suite failed and you need to know why. Also invokable as /ginkgo:debugging-failures.
- ▌ Timeouts And Async · onsiMake Ginkgo specs interruptible and test asynchronous behavior — SpecContext/context.Context cancellable nodes, NodeTimeout/SpecTimeout/GracePeriod, the --timeout flag, Abort and SIGINT behavior, Gomega Eventually/Consistently (the func(g Gomega) form, .WithContext), and the defer GinkgoRecover() rule for goroutines. Use when a spec hangs or times out, polls for eventual consistency, tests channels/streams/processes, launches goroutines, or needs a deadline.
- ▌ Ordering And Flakes · onsiControl spec ordering and manage flaky specs — Serial, Ordered containers with BeforeAll/AfterAll/ContinueOnFailure, OncePerOrdered, SpecPriority, plus FlakeAttempts/--flake-attempts, MustPassRepeatedly, --repeat, and --until-it-fails. Use when specs must run in a fixed order, you need once-per-group setup, you're combining Serial+Ordered, a spec is flaky, or you want to hunt order-dependence with --until-it-fails -p --randomize-all.
- ▌ Tables And Dynamic Specs · onsiParameterize and generate Ginkgo specs — DescribeTable/Entry table-driven specs, Entry descriptions (string, nil, closure, EntryDescription), PEntry/FEntry and per-Entry decorators, DescribeTableSubtree, generating specs in a construction-time loop, loading fixtures in TestXxx before RunSpecs, and shared-behavior closures. Use when you have repetitive specs differing only by inputs, want data-driven or generated specs, or are extracting reusable It blocks across Contexts.
- ▌
- ▌ API · onsiOne-line reference for every Biloba Go method and matcher, grouped by area — selectors/locators, lifecycle, poll-config (WithTimeout/WithPolling/WithContext/Immediate), capturing a matcher's observed value (.Capture), navigation (GetLocation/GetTitle), cookies/storage, tabs, DOM existence/visibility/contents/properties/forms, clicking and interactions (incl. drag/scroll/tap/modifiers/text-selection), realistic mode, keyboard, uploads, element JS, dialogs, downloads, arbitrary JS (incl. the GetJSValue app-state barrier), network stubbing/aborting/modifying/observing/holding (HoldResponse + Limit/ReleaseNext), screenshots/outline/window, and visual regression (HaveScreenshot + Mask/Tolerance/ChannelTolerance/Animated/InColorSchemes). Use to look up the exact Go method or matcher name and shape. Methods marked (dual) poll until they succeed when fully applied and return a pollable matcher when under-applied.
- ▌ Biloba Testing · onsiHow to write and run Biloba's own Ginkgo test suite. Use when adding or modifying specs in this repo, asserting that a Biloba call should fail the test, working with the fixture server, or running the suite (including the driver, parity, e2e, and npm packaging lanes). Covers the run commands, the failure-capturing gt/bilobaT harness, ExpectFailures, fixtures, and spec structure.
- ▌ Setup · onsiWire Biloba into a Go Ginkgo/Gomega suite — go get, the bootstrap file (SynchronizedBeforeSuite + Prepare), chrome-headless-shell installation, high-fidelity vs fast headless modes, shared vs per-process browsers, reusable vs fresh tabs, window size, screenshot and baseline directories, and running the suite. Use when setting up Biloba's Go API or changing its suite-level Chrome lifecycle.
- ▌ Xpath · onsiBuild XPath selectors with Biloba's Go b.XPath() mini-DSL — tag/id/class/text/attribute predicates, boolean logic with b.XPredicate(), tree navigation (Child/Descendant/Parent/Ancestor/siblings), WithChildMatching + b.RelativeXPath, indexing (Nth/First/Last), and the XPath().WithText text predicates. Use when constructing or debugging an XPath selector for a Biloba action or matcher — the rare power tool after CSS and semantic locators. Covers the common pitfalls (XPredicate, RelativeXPath, ancestor-or-self, no shadow/iframe crossing).
- ▌ Biloba Dom Method · onsiHow to add a new DOM interaction or matcher to Biloba (a browser-action method like Click/SetValue/HaveProperty). Use when adding or modifying a browser-side primitive that touches biloba.js and the Go wrapper, or when implementing the dual immediate/matcher API. Covers the JS bridge, the gcustom matcher pattern (including a matcher whose failure message has a side effect, which embeds CustomGomegaMatcher and overrides FailureMessage), capturable value matchers (*ValueMatcher/.Capture) and the getters' optional decode pointer, missing-element-is-an-error vs silent-retry, when to return gomega.StopTrying, first-vs-all (Each) variants, tests, and docs.
- ▌ Overview · onsiThe Biloba mental model for writing browser tests in a Go Ginkgo/Gomega suite — pragmatic simulation, poll-by-default, dropping to chromedp, and visual regression against committed baselines. Use first when starting with Biloba or deciding whether it fits a Go browser-testing task. Routes to the other skills in this plugin.
- ▌ Flake Hunt · onsiRun a flake hunt on a Biloba Ginkgo suite — run the whole browser suite many times (60 by default), every run to completion with its own JSON report, then read each spec's failure rate, the seeds, and Biloba's failure evidence out of those reports instead of re-running. Covers the hunt script (compile once, --procs at the measured knee, --randomize-all, --poll-progress-after, a per-run BILOBA_SCREENSHOTS_DIR), why --repeat and --until-it-fails can't measure a rate, what keeps a hunt a valid measurement (one hunt at a time on an idle machine, nothing editing the tree, focused hunts for iterating only, stale visual baselines), how many clean runs it takes to call a flake dead, reading the results (one systemic race behind many names, wedges, a long tail that clusters by run), and the performance record a hunt produces (spec timing, parallel efficiency, per-spec cost, drift between hunts). Use before declaring a flake fixed, after changing shared test helpers or fixtures, at the end of a batch of work, or to mea
- ▌ Flaky Specs · onsiDiagnose and prevent flaky Go/Ginkgo Biloba specs — specs that pass locally but fail in CI, fail intermittently under `-p` or load, or fail somewhere other than the line that is actually wrong. Biloba polls by default, so the headline rule is "don't reach for b.Immediate()". Covers the residual smells — single-shot `b.Run(expr,&x)` reads and gate-then-re-read pairs (fix with .Capture); the non-polling SendKeysToWindowImmediately and `*Immediately` verbs; optimistic-UI and server-reconciliation traps (barrier on app state with b.GetJSValue, force the arrival order with b.HoldResponse + Limit/ReleaseNext); async-settling geometry, layout, and document-order reads; AllowMissing for properties absent on the element type; network handlers accumulating across an Ordered container; vacuous assertions that can never fail (an unresolved locator scope, BeNetworkIdle before the request starts, an empty Current*ForEach under a negation, a visual baseline written without ever being reviewed, a screenshot tolerance widened
- ▌ Write Tests · onsiAuthor Biloba specs in a Go Ginkgo/Gomega suite — the dual immediate/matcher API (act now vs. return a matcher you poll with Eventually), capturing a matcher's observed value with .Capture instead of asserting-then-re-reading, first-vs-all naming, the navigate-then-readiness-anchor shape (gate on the DOM, then read GetLocation), selecting elements (CSS targeting stable hooks as the default, semantic role/text/label locators, anchoring a locator scope so a negative assertion isn't vacuous, the >>> piercing combinator, XPath), the interaction vocabulary (click variants, drag, scroll, tap, text selection), realistic mode for occlusion/hover smoke tests, visual regression with b.HaveScreenshot against a committed baseline, hermetic tests via request stubbing/aborting/modifying/holding, the GetJSValue app-state barrier (and when it gates nothing), multi-tab flows, and seeding state. Use when writing or reviewing Biloba browser tests.
- ▌ Debug Failures · onsiSee why a Go/Ginkgo Biloba spec failed or flaked — the on-failure artifacts (DOM outline + screenshots + poll trajectory of the timed-out read + the visual-regression diagnosis with its .actual.png/.diff.png, the "never settled" warning an update run prints + the detached-node "matched then stopped matching" signal + the occluded-click diagnosis naming what covered the target), how Biloba auto-adapts to humans vs CI vs AI agents, the env vars and config knobs that surface them (BILOBA_SCREENSHOTS_DIR, BILOBA_SCREENSHOT_BASELINES_DIR, BILOBA_UPDATE_SCREENSHOTS, BILOBA_INLINE_SCREENSHOTS, BILOBA_OUTLINE_MAX, BILOBA_INTERACTIVE, BilobaConfig*), attaching app/store state to a failure, headless quirks (stale innerText, unscheduled requestAnimationFrame), and using b.Outline()/b.A11yOutline() to understand why a selector did not match. Use when a browser spec is failing or flaky and you need visibility, or to configure failure output for CI/agents. For *preventing* flakes (single-shot reads, avoiding b.Immediate(),
- ▌ Realistic Mode · onsiUse Biloba's realistic interaction track (b.Realistic()) in a Go Ginkgo/Gomega suite 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.
- ▌ Flaky Tests · onsiDiagnose and prevent flaky Biloba TypeScript/Vitest tests — redundant client-side retry loops, immediate mode, single-shot evaluate reads, optimistic UI, async layout, first-match-wins network handlers, held responses, vacuous assertions, visual update/tolerance hazards, and lifecycle leakage. Use when a Biloba Vitest test is intermittent, order-dependent, load-sensitive, or only fails in CI/parallel workers.
- ▌ Visual Assertions · onsiAssert that a page or element still looks right with Biloba's Go/Gomega visual regression matcher (b.HaveScreenshot) — writing the assertion, the golden-master workflow for creating and updating committed baselines with BILOBA_UPDATE_SCREENSHOTS=1 (review the .actual.png, update mode settles to three consecutive equal captures before writing so a write is not instantaneous, the actionable "never settled" warning, commit the baselines dir, never set the var in CI, nothing prunes orphaned baselines), reading the text diagnosis of a failed comparison without opening an image, and the determinism tools (b.Mask for timestamps/avatars, the automatic animation freeze and b.Animated() to opt out, b.Tolerance/b.ChannelTolerance, b.InColorSchemes for light+dark). Also covers the two directories (committed baselines vs gitignored actual/diff artifacts), the ways a visual assertion can go silently vacuous (a subject clipped out of its own capture by an inner scroll container, two colour schemes that render identically),
- ▌ Explore Unfamiliar Page · onsiOrient to an unfamiliar page, then draft a starter Go/Ginkgo Biloba spec from its DOM outline, accessibility tree, and screenshot. Use when writing browser tests against a URL or fixture you have not seen. Covers the orient-author-cleanup loop and accepts a URL or fixture argument when invoked explicitly.