The file format drafted in T219883: Draft file format for phester test definitions needs to be finalized and documented, once we have a feature complete (prototype?) implementation of phester.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | Atieno | T219873 Create a suite of end-to-end API test for MediaWiki core | |||
| Invalid | None | T219879 Create a test runner for end-to-end API tests (Phester) | |||
| Invalid | None | T222103 Finalize file format for phester test definitions | |||
| Resolved | • Clarakosi | T219883 Draft file format for phester test definitions |
Event Timeline
Comment Actions
Giving this 3 story points, tending towards 5, because writing a proper spec with good documentation takes time, even after we know exactly what the file format should look like.
Comment Actions
Phester's format for specifying requests and responses is quite similar to HAR (see HTTP Archive 1.2), but there are some differences. Maybe we want to change the format to be compatible with HAR?
Comment Actions
Accessing values nested deeply in a structure. We could allow a shorthand syntax for that. E.g. instead of
body:
query:
page:
62323:
user:
id: 23we could allow:
body: .query.page.62323.user.id: 23
The path-like key would be expanded after parsing the YAML. The leading dot would trigger that. The syntax follows the JSONPath standard (though I don't think we should implement full JSONPath here). To allow for the rare case that we literally want a key that starts with a dot, escape it with a backslash (or another dot).