feat: e2e tests

[Benehiko]

Related Issue or Design Document

https://github.com/ory/elements/issues/4

Checklist

• [ ] I have read the contributing guidelines and signed the CLA.
• [ ] I have referenced an issue containing the design document if my change introduces a new feature.
• [ ] I have read the security policy.
• [ ] I confirm that this pull request does not address a security vulnerability. If this pull request addresses a security vulnerability, I confirm that I got green light (please contact security@ory.sh) from the maintainers to push the changes.
• [ ] I have added tests that prove my fix is effective or that my feature works.
• [ ] I have added necessary documentation within the code base (if appropriate).

Further comments

[Benehiko]

:construction: This is a work in progress :construction:

[Benehiko]

Nice work! This is looking great, and I have just a few nits. I was a bit skeptical, when you said you're mocking stuff in E2E tests, but this is looking really solid. Do you have a strategy for keeping everything up-to-date as stuff changes in Kratos?

As it stands, I don't see how this test suite would prevent issues arising from changes to the Kratos flow responses changing, as we don't seem to have a mechanism to test the mocks against the source-of-truth (Kratos master).

Yeah this is a difficult topic and I don't think there is one good solution other than having the tests executed against a live Ory Network project as well. I think before we go down the rabbit hole of topics, the main goal of this PR is to create a foundation of common reusable e2e test selectors and functions which test for integration compatibility with Ory Network.

The 2 sub-goals are:

1. Test Ory Elements (through the examples that live inside the monorepo)
2. Expose a reusable library for others to test their projects against Ory Network

Right now the library is only capable of checking if the UI implementation is correct between Ory Elements and Ory Network, essentially are you calling the right APIs? Are you giving back the right expected data to Ory Elements from the API? Since the data is mocked, we actually do not care if the flow data is equivalent to the Ory Networks response data (for now at least) since we only care about the expected result of Ory Elements.

Here is an example:

I want Ory Elements to render a form with the csrf token and 
an input field for email with the email pre-filled. 
There should also be a submit button and once clicked the
expected API endpoint should be called with the post data. 

In this scenario we won't ever just have just an email input since we also send down a password input from Ory Network. But this scenario checks if the SDK is giving the data correctly from the mock response to Ory Elements and Ory Elements knows what to do with that data since the format is correct.

---

Future goals:

We can reuse this testing library in the Account Experience and actually test all flows and use cases against the real Ory Network API. We already do this, but to a large extend it is split up into multiple repositories ( we have discussed this topic already of circular dependence).

What that would mean is we would run these e2e tests using the current Account Experience. With this step we could improve updating fixtures inside our testing library to match what is given by the Ory Network.