feat: poc integration tests for identities management express.js samples

[wassimoo]

This PoC introduces integration tests for Ory Identity session management flows, ensuring that the code examples in our documentation work correctly end-to-end.

The tests run against a test Express.js server that directly imports and uses code examples from the documentation.

While the tests use Ory's self-service API for login (via selfServiceLogin() utility), they validate the complete end-to-end flows for:

1. Logout Flow: After authenticating via self-service API, the tests verify that the logout endpoint in the example app correctly handles session termination and redirects appropriately.

2. Session Management Flow: Tests verify that authenticated sessions can be retrieved and validated through the example app's session endpoints.

Tests run in GitHub Actions with secrets injected for:

• ORY_SDK_URL - Ory test account endpoint URL
• TEST_USER_EMAIL - Test user credentials
• TEST_USER_PASSWORD - Test user credentials

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 approval (please contact security@ory.com) 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 the necessary documentation within the code base (if appropriate).

Further comments

[zepatrik]

While the overall approach looks good, I'm thinking whether it makes more sense to have everything in one file. What you have is a bit more boilerplate (passing the SDK and exporting again), while the reader might want to have everything in one file in the end when copy-pasting. The current content is meant to be all in one file, while yours is meant to be split up. I'm pretty sure you can cut the code up into sections and only show parts of it for each code box. WDYT?

[wassimoo]

While the overall approach looks good, I'm thinking whether it makes more sense to have everything in one file. What you have is a bit more boilerplate (passing the SDK and exporting again), while the reader might want to have everything in one file in the end when copy-pasting. The current content is meant to be all in one file, while yours is meant to be split up. I'm pretty sure you can cut the code up into sections and only show parts of it for each code box. WDYT?

While a single-file approach works for copy-paste, the modular approach serves both documentation and testing. We can show focused snippets in docs, and integration tests require combining multiple unrelated samples in one server. Splitting into modules lets us:

• Combine unrelated samples in one test setup without duplicating code
• Present cleaner, focused examples in the docs while reusing the same code for testing
• Scale to cover more samples without creating large monolithic files

@unatasha8 You may want to give your opinion on this?

[unatasha8]

While the overall approach looks good, I'm thinking whether it makes more sense to have everything in one file. What you have is a bit more boilerplate (passing the SDK and exporting again), while the reader might want to have everything in one file in the end when copy-pasting. The current content is meant to be all in one file, while yours is meant to be split up. I'm pretty sure you can cut the code up into sections and only show parts of it for each code box. WDYT?

While the overall approach looks good, I'm thinking whether it makes more sense to have everything in one file. What you have is a bit more boilerplate (passing the SDK and exporting again), while the reader might want to have everything in one file in the end when copy-pasting. The current content is meant to be all in one file, while yours is meant to be split up. I'm pretty sure you can cut the code up into sections and only show parts of it for each code box. WDYT?

While a single-file approach works for copy-paste, the modular approach serves both documentation and testing. We can show focused snippets in docs, and integration tests require combining multiple unrelated samples in one server. Splitting into modules lets us:

• Combine unrelated samples in one test setup without duplicating code
• Present cleaner, focused examples in the docs while reusing the same code for testing
• Scale to cover more samples without creating large monolithic files

@unatasha8 You may want to give your opinion on this?

I understand the value of the 1 file for copy/pasting, but for these code examples I prefer to keep them separate files for the same reason's that Wassim mentions above. We want to be able reuse code examples and provide guidance along side snippets. When we create larger solution-level examples, it makes sense then to have one file for customers to copy/paste as a starting point for their code.

[unatasha8]

LGTM

[unatasha8]

Reopening...

[zepatrik]

Great, a lot less boiler plate now! 🎉

[zepatrik]

What I meant before was that you can always load just show parts of the single file in the docs, e.g. using

docs/src/theme/CodeFromRemote.tsx

Lines 84 to 85 in 3581575

	startAt?: string
	endAt?: string