Loading
fix(D010, D013, D016): distributed retrieve and batch assertions
- D010_01_aux / D010_01_red: the local entity is created from the .jsonld fixtures (body @context), and D010_01_aux retrieves with the suite context and expects the compacted 'brandName', not its expanded IRI.
- D010_01_exc: the stub count queried the by-type URL, never stubbed nor requested; it now counts the by-id stub the test registers. The speed check uses Dictionary Should Contain Key (Should Contain on a value).
- D010_03_inc: the queryEntity leg is stubbed at /entities?id= - a query forwarded for one entity - and handled as retrieveEntity is.
- D013_01_red / D013_02_red: the second registration was posted with the first one's id (409 AlreadyExists, the setup failed); it now uses ${registration_id2}, as D006_01_red does. The forwarded entities are compared without @context: the forwarded request may carry its context in the Link header (TS 104-176 clause 6.3.5).
- D016_01_inc / D016_01_red:
Should Contain ${response.json()} speedtested whether the string is an element of a list of entities; they now check the speed key of each entity. D016_01_red's mock sources reply with the merged entities, with their own @context. - HttpCtrl http_stub: a GET stub with no query parameters and no id matches on its decoded path, whatever optional parameters (pick, sysAttrs, ...) the broker adds to the forwarded request.
Tested - Against coraine, DistributedOperations (101 TCs): develop 60 pass / 41 fail, this branch 66 / 35 - D010_01_red, D010_03_inc_02, D013_01_red, D013_02_red, D016_01_inc, D016_01_red; nothing else changed.
Edited by Ken Zangelin