You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We'll have to prepare for test cases where we need to have requests and checks that depend on the result of other requests.
For example:
A test wants to query an endpoint, retrieve the ETAG from the response, then check that subsequent calls to the same endpoint reusing the ETAG value gives a 304 - Not Modified.
We used a minimal approach to implement these test:
- define empty variable "etag"
- call Run(test1), which has a Function Check which updates "etag" with a side effect
- call Run(test2, test3) which reuses "etag".
We used a minimal approach instead (PR), which does the side-effect explicitly, without endorsing it in the API.
That won't scale to more complex test cases, and we should be ready to implement a "better" approach, ideally, that should:
make dependencies explicit
be declarative
be compatible with the rest of the API (templates, decorators used to generate more tests)
play nice with IDEs and tooling (use variable instead of raw strings, etc).
Using futures values should work: a future might "taint" values and templates where they are used (templating with a future returns a future). At evaluation time, we can do a topological sort to find the order of execution.
We'll have to prepare for test cases where we need to have requests and checks that depend on the result of other requests.
For example:
A test wants to query an endpoint, retrieve the ETAG from the response, then check that subsequent calls to the same endpoint reusing the ETAG value gives a 304 - Not Modified.
We used a minimal approach to implement these test:
@galargh investigated a few approaches:
We used a minimal approach instead (PR), which does the side-effect explicitly, without endorsing it in the API.
That won't scale to more complex test cases, and we should be ready to implement a "better" approach, ideally, that should:
Using futures values should work: a future might "taint" values and templates where they are used (templating with a future returns a future). At evaluation time, we can do a topological sort to find the order of execution.
Refs:
The text was updated successfully, but these errors were encountered: