[FEATURE] Test generation (with mocks)

[SamuelMarks]

Is your feature request related to a problem? Please describe.
OpenAPI is used by both first-party and third-party systems alike. Being notified—e.g., by ones regular CI/CD—when the interface changes would be useful in catching incompatibilities early.

Describe the solution you'd like
In addition to generating tests, mocks also.

Describe alternatives you've considered
Open-source:

• https://dredd.org
• https://github.com/tuwilof/fitting
• https://github.com/pb33f/openapi-changes

However each of these—and others, see https://openapi.tools/#testing—are focussed on particular languages frameworks (which are not Angular) or as a language-agnostic tool. Therefore they would require special setup—separate from existing Angular test runner—in CI.

Additional context
In the early days of Angular there was a mock server also. This could be brought back to life by this project; if this feature were implemented first. Or some sort of HttpInterceptor extending implementation.

Thanks for your consideration of this feature

[Mr-Jami]

Hey @SamuelMarks
Interesting feature. I took a quick look into the open source solutions you have provided and I see your point.

I can think of two things that could be tested or at least make sense to be tested (imo):

• whether the generated code matches the openapi spec
• Testing the Angular Service (https://angular.dev/guide/testing/services) and probably setup a mock server or use the actual server to test the functions.

Regarding a mock server or testing the APIs in general. I need to research a bit more. I would love to hear insights from you or perhaps if you created some kind of a testing environment, I would be interested to see how its being used and implemented.

Nevertheless, since ng-openapi is focused on providing Angular first solutions, it would be really interesting to implement testing features for Angular using Angular native tools.

[SamuelMarks]

Thanks

Yeah you're right.

Trying to think of the exact APIs to use… he's updated the course, but I remember there was something similar in Angular 4:
https://egghead.io/lessons/angular-mock-http-requests-made-with-angular-s-httpclient-in-unit-tests

TL;DR https://angular.dev/guide/http/testing

In terms of major use-case out of this, I am considering two new features requests, one of which I would like to take:

• Auto-admin (with tests being the source of truth)
• Generate OpenAPI from Angular (I'll take this feature; if you like)

[Mr-Jami]

Hey @SamuelMarks
Thank you for providing the video guide for testing a service that utilizes the HttpClient.
The only thing I struggle to understand, at least from the video, how is that test being benefitial, if the tests are being auto-generated?

Lets assume we generate pet.service.ts & pet.service.spec.ts. We are going to test getPetById(id: number): Pet. Now the approach in the video would be by basically just mocking that and return an object that satisfies the Pet properties. And since the spec file is auto generated, it should always return the appropiate response. Which would result the tests to always succeed.

The other case, which would make more sense imo, would be to basically fetch the actual API from an actual backend. But then you wouldn't be able to combine tests (e.g. post and a new Pet and try to get that Pet by the new Id).

I am trying to fully grasp the benefit of having these tests. I would appreciate it if you could explain it further to me.

Generate OpenAPI from Angular (I'll take this feature; if you like)

I just saw your new issue (#40) It seems to be very interesting. I am not 100% sure how this should look like. BUT I am excited to see your creation. Let me know, if you have any questions!

[SamuelMarks]

@Mr-Jami Good questions; thanks for your attention.

In answer to them:

• Tests can completely mock the backend, never hitting a real server
• Tests can confirm the backend really is compliant with this interface
• Tests can be composed. So yes a mocked backend will obviously succeed everytime. But when you bring in edge cases, the tests can help confirm bug presence / absence.

To expand on that last with an example:

0. Create three Users
1. Create an Article by one unique User
2. Create a Comment by one different unique User
3. Create a Comment on that [aforementioned] Comment by the third unique User
4. Test:

• Deleting first Comment;
• Deleting Article

Now these tests could be configured to run—depending on, e.g., argument provided—to hit the real server or the mock one. It is not obvious from the OpenAPI spec how to write these tests, e.g., does deleting the first Comment raise an error because a child Comment exists for it? - This is domain specific business logic, requiring custom tests to be written to confirm desired functionality.

That's the benefit from having a preexisting; composable; test suite.

[Mr-Jami]

@SamuelMarks
I see. Your example is valid. Although I would do that kind of a test in the frontend, only if I don't have access to the backend repository so I can't do any integration tests in there and I don't trust the backend developers with their work 😆

Because as you mentioned, you would get into domain specific business logic and usually that should be maintained in the backend and not in the frontend.

Is it possible for you to create an example spec file for a small service (maybe containing each of the CRUD methods), so I could see how a developer could integrate this into their work.

Oh and do you mind, if I take this discussion further to the Angular Community(Discord/Reddit), to get some insights and ideas about this? I have the feeling I am still not seeing the whole picture 😅

[Mr-Jami]

Hey @SamuelMarks
After further discussions within the Angular community and other fellow developers. I decided to not include test generations within this library.

I would rather suggest writing the tests manually. This would give us the ability to test the generated services properly. Generating the tests automatically makes it difficult to recognize whether the generated services are working properly. Also it is not possible to test domain logic based on the openapi spec only.

Nevertheless, I am still open for ideas that generate tests that include domain logic and better test cases. (if possible)

[SamuelMarks]

Thanks yeah understood @Mr-Jami… I might be maintaining a separate library that will be about ⅔ bigger than this repo; maybe even 3× the size of yours.

I'll retain the MIT-only license [for now] to keep open the option of contributing code back to you. In the future I am interested in expanding to (Apache-2.0 OR MIT) or even (Apache-2.0 OR MIT OR CC0) licenses.

In the interim, I'll be focussing on:

• Codebase wide test coverage
• Codebase wide type safety
• Codebase wide documentation coverage
• OpenAPI spec compliance
• Auto-admin generation
• Tests + mock generation
• Tests generation for auto-admin

I'll check in every two to four weeks to give you some updates as to where I've gotten it to, and to see what—if any—you would like PRs for; as I like the give and take of open-source.

Thanks again for creating ng-openapi,

[Mr-Jami]

Hey @SamuelMarks

that sounds great! I'm glad you like the project and will be excited and follow the your development on your library. I will definetly appreciate any contribution from your side, especially any improvements in the main ng-openapi package!

Keep it up man!