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
This adds integration tests that test the core functionality of the SDK.
I had originally written these as a single `describe` containing four
`it`s, each of which included the test setup and then a list of
scenarios, these scenarios just being separated by comments. However,
Dom was keen for me to make more use of the vitest APIs for structuring
my tests. This resulted in the current setup, where there is one
`describe` for each area of functionality, each of these `describe`s
then containing multiple `it`s. Each `it` within a given `describe`
relies on the side effects of the previous `it`s within that `describe`.
Dom preferred this new approach and was happy to accept the compromises
that this resulted in, such as having `describe`-level local variables
which have no type information, and the fact that the failure of one
`it` does not prevent the subsequent `it`s (which rely on the
preceding `it`s all having succeeded) from running.
With my initial approach, I was able to get the tests running in
parallel using `describe.concurrent` on the top-level `describe`. I
wasn’t able to figure out how to achieve this in the new approach, in
which we want to run all `describe`s in parallel, but run the `it`s
within a given `describe` sequentially. I tried using `.concurrent` on
the top-level `describe` and `.sequential` on each nested `describe`,
but it still just ran everything sequentially.
Resolves COL-56.
0 commit comments