Add improved assertion library from folio

[andrewvc]

At the moment we're unopinionated about assertions, but, this is something we should probably bake in. One thing to consider would be Microsoft's folio/expect.

We would alias it, so users could import it like import { expect } from '@elastic/synthetics'

As-is, we rely on assert in examples, which is too minimal. While users can use any library, it's good to have one sanctioned one, especially for inline examples (where we should just provide expect.

@vigneshshanmugam @jahtalab @paulb-elastic would love your thoughts here

[paulb-elastic]

I agree we should make this easier with a more out of the box solution, and this seems a good choice (given the wider Framework’s association with Playwright/runner). As the framework is still only in preview with potential breaking changes, would we want to hold off implementing this into Synthetics GA until it’s ready (users still have the freedom to use assertions like we document today, or add Folio or an alternative)?

[andrewvc]

It's important we do something prior to GA that users can depend on. assert is just not great, and I can't see a downside to this approach. We really want 95% of use cases to be able to be accomplished without external libraries IMHO. It will tighten our documentation, and let users focus on writing tests rather than choosing tools.

[hmdhk]

I agree with that the majority of use-case should be supported out of the box without an external lib.
Re. the breaking changes in folio, since we are exposing the methods from our library, we should be able to handle these changes as we keep up with folio releases.

[vigneshshanmugam]

Not sure if you are aware, Folio assertion (expect) uses the Jest's expect which is what we should be going for and its released as a standalone package - https://www.npmjs.com/package/expect.

Another cool thing is that we can also add our own matchers by extending the expect.extend - https://jestjs.io/docs/expect#expectextendmatchers and provide functionality like comparing steps screenshots or performance timing events values. Just thinking out load, we don't need it for the first phase.

[andrewvc]

+1 on just using Jest directly