CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/async-ordering-tests

Test async ordering - event-loop / queue / channel ordering assertions, JS Promise microtask vs macrotask ordering, Python `asyncio.gather` vs `asyncio.wait_for` semantics, Go goroutine + channel happens-before relationships, async/await re-entrancy. Use deterministic schedulers (sinon fake timers, asyncio test mode) to remove run-to-run variance. Use when a callback fires twice, a later response overwrites an earlier one, or a cancelled parent task leaves a child still running - bugs where completion order, not shared memory, is the defect.

87

1.00x
Quality

86%

Does it follow best practices?

Impact

94%

1.00x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

criteria.jsonevals/scenario-2/

{
  "context": "Out-of-order response handling in a keystroke-driven search controller. Predicted baseline failure: the agent simulates 'slow' and 'fast' requests with setTimeout delays of, say, 50ms and 10ms, then awaits both. The assertion is correct but the ordering is a property of the runner's timer scheduling rather than of the test, so it drifts on loaded CI and proves nothing about the guard. The skill's value is that completion order is controlled explicitly - deferred promises the test resolves in a chosen sequence - so the interleave under test is stated, not hoped for.",
  "type": "weighted_checklist",
  "checklist": [
    {
      "name": "Test file created",
      "description": "A file src/searchController.test.js exists and contains at least one test.",
      "max_score": 4
    },
    {
      "name": "Completion order controlled explicitly",
      "description": "The test holds each search response open and settles them in a chosen order - deferred promises with externally held resolve functions, a manually driven queue, or an equivalent. Ordering the responses by giving them different real-time delays scores zero on this criterion: the interleave is then decided by the scheduler, not the test.",
      "max_score": 32
    },
    {
      "name": "Superseded response does not overwrite current results",
      "description": "A test starts a request for an earlier query, starts a request for a later query, settles the later one first and the earlier one second, then asserts the snapshot holds the later query's results. This is the defect described in the ticket; a suite without this exact sequence scores zero here.",
      "max_score": 24
    },
    {
      "name": "Superseded call reports why it did not apply",
      "description": "The stale call's return value is asserted to carry applied false with reason SUPERSEDED, not merely ignored. Asserting only the final snapshot leaves the guard's own contract untested.",
      "max_score": 14
    },
    {
      "name": "In-order case still applies",
      "description": "A test settles two sequential queries in their natural order and asserts the second one's results are applied, showing the guard suppresses only genuinely superseded responses rather than everything after the first.",
      "max_score": 12
    },
    {
      "name": "Both requests are in flight simultaneously",
      "description": "MUST NOT await the first run before starting the second. Both invocations are started before either is settled; awaiting the first to completion serialises them and removes the condition under test, scoring zero on this criterion.",
      "max_score": 10
    },
    {
      "name": "No real-time delay anywhere in the test",
      "description": "MUST NOT. The file contains no setTimeout-based sleep, no real-delay promise, and no 'let things settle' wait. Any single instance scores zero here.",
      "max_score": 10
    },
    {
      "name": "Fresh controller per test",
      "description": "MUST NOT share one controller across tests at module scope; its sequence counter is mutable state that would carry between cases.",
      "max_score": 4
    }
  ]
}

SKILL.md

tile.json