E2E testing infrastructure

[habbes]

While we do have tests to verify that the generate code looks as expected and compiles without errors, we don't have tests to verify that the code we generate runs as expected. We achieve that using manual testing, which is tedious and not enforced. We should consider setting up automated E2E testing to automate catching issues that we can currently only detect via manual testing.

For example, an E2E test could run the CLI to generate client code based on some schema and settings, add a predefined Program.cs file that calls the generated client code against some test OData service, and verify that the code ran as expected by inspecting the program output.

[rpallares]

May be another flow could have an asp.net odata server with a simple model and sample data.
The test will run the server and cli generates the client using the fresh csdl.
Then you Can perform E2E tests against that server.
Any server side change is immediately replicated to the client as all parts are built AT the same time.
Sadly there's no tool like https://learn.microsoft.com/fr-fr/aspnet/core/fundamentals/openapi/openapi-tools to generate the csdl file AT build time as WE do for openapi. I resolved that by executing my server with a dedicated parameter to generate it locally in command line.
Not very elegant but it works well.

[paulodero]

@habbes Can we get more examples/scenarios where E2E testing will be needed? Doesn't seem like we need E2E testing to detect conflicts.