test: add the UTS harness for derived REST unit tests - #698
owenpearson wants to merge 3 commits into
Conversation
|
Warning Review limit reachedNext included review available in 59 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (13)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
d7aaa69 to
9d872cb
Compare
9d872cb to
08d704d
Compare
08d704d to
18b4077
Compare
18b4077 to
8b94569
Compare
8b94569 to
9fbce72
Compare
9fbce72 to
5987d52
Compare
The Universal Test Specifications serve every unit test's requests from a mock and reach no network. This adds that mock as an httpx transport, so it installs through the seam the client already exposes, along with the connection, request and response objects the specifications' pseudocode drives it through. Its own tests go through a real AblyRest client rather than calling it directly, so the contract they pin is the one derived tests will rely on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Client construction and teardown the specifications assume, the two gating markers a derived test can carry, and the skeleton of the record those markers point at. `time.md` comes with it as the first derived specification: it is short, exercises the mock end to end, and its `/time` fixture is the one the sibling specifications reuse. A derivation is a mechanical translation, and the traps particular to this SDK are not obvious from the specification text, so the skill records them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
deviations.md gains a closing section on the choices behind the harness: what a derived test may and may not change, and where this SDK's shape forced a choice. Everything above it records behaviour; this records the approach. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
5987d52 to
02f925d
Compare
02f925d to
092377a
Compare
|
|
||
| ## Timers | ||
|
|
||
| There is no clock seam. `ably/http/http.py` calls `time.time()` directly. Where a spec calls |
There was a problem hiding this comment.
I would expect timers to be mocked, it's more deterministic. I think it's worth to group all timer related functions in a single abstraction (let's say clock, we already have it for realtime uts, but it only for timers, it doesn't mock time.time()/time.time_ns() calls). we can also add to claude.md that all things related to time should go through this clock() interface and direct access to time is forbidden
| on_connection_attempt=lambda conn: conn.respond_with_success(), | ||
| on_request=lambda req: req.respond_with(200, {'result': 'ok'}), | ||
| ) | ||
| ably = AblyRest(key=key, test_options=TestOptions(http_transport=mock_http.as_transport())) |
There was a problem hiding this comment.
I am thinking maybe it's better to name test_option with _ to mark it's internal thing? (key=key, _test_options=TestOptions(http_transport=mock_http.as_transport()))?
ttypic
left a comment
ttypic
left a comment
There was a problem hiding this comment.
approved with a comment that we can discuss on the later PRs in the stack
This branch was successfully deployed
2 participants
PR 4 of 9 in the UTS REST unit stack. Base:
uts/message-id-and-decoding.The infrastructure the derived tests need. No library changes — from here to PR 9 the stack
is tests and docs only.
helpers/mock_http.py— the mock HTTP client the specifications assume, as anhttpxtransport so it installs through the seam from PR 1, with the connection, request and
response objects their pseudocode drives it through. Its own tests go through a real
AblyRestclient rather than calling it directly, so the contract they pin is the one thederived tests rely on.
helpers/client.py,conftest.py— client construction and teardown, with an autousefixture that closes whatever a test built, whether or not its assertions held.
helpers/deviations.py— the two gating markers a derived test can carry:@deviationwhere the SDK departs from a specification,
@spec_errorwhere the specification is atfault. Both are
skipifonRUN_DEVIATIONS, so the suite runs green by default and a realregression still shows.
rest/unit/time_test.py— the first derived specification, included here because it isshort, exercises the mock end to end, and its
/timefixture is the one the siblingspecifications reuse.
deviations.md— the single recordwriting-derived-tests.mdasks for. Its fourheadings are fixed and each of PRs 5–9 fills in the entries for its own area, so a reviewer
meeting a gated test finds the reason in the same diff. It also carries the faults found in
the specifications themselves, with the upstream issue each was filed as, and closes with
how the specifications are adopted here: what a derived test may and may not change, and
where this SDK's shape forced a choice.
.claude/skills/uts-to-python/SKILL.md— the derivation traps particular to this SDK,which are not obvious from the specification text.
Review notes
deviations.mdis the document worth reading in full; it sets the rules the next five PRsare judged against.
Verification
130 passed(test/unit+test/uts);ruff check ably/ test/clean.🤖 Generated with Claude Code