Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collect real life open api examples for testing #8

Open
sh-rp opened this issue May 3, 2024 · 0 comments
Open

Collect real life open api examples for testing #8

sh-rp opened this issue May 3, 2024 · 0 comments
Assignees

Comments

@sh-rp
Copy link
Collaborator

sh-rp commented May 3, 2024

TLDR
We need a bunch of examples from real world openapi specs to test the following things:

  • Discover which pagination is used and which are the correct fields to look at when paginating
  • Discover the correct primary key on an object
  • Discover the json path under which to find the "real" result objects of an endpoint, both list and single entity endpoints
  • Discover the parent/child relationships of endpoints and mapping the url parameters to a field on a parent object
  • Discover the correct auth setup (I think this is very well defined though in the openapi spec and we do not need many examples, you could still verify that it is done correctly though)
  • Still create useful output from the generator if the spec is incomplete or broken

Preparation
Basically this generator project converts an openapi spec into a dlt source that uses our new rest_api source that is configured with a dict. To prepare you need to:

  • Understand how our rest_api source works, since you've done the 2nd hackathon, you should know it I think, but anyhow it's good to recapitulate
  • Try out this tool on one or two specs. Check the makefile to see how to generate a pipeline from an url (the endpoint selector currently does not work, I'll fix that in a bit). You can also use the --path option to generate from a local file.

Task
I would start with looking at specs of the biggest APIs, convert them with this tool and see what the outcome is. Then:

  • If something is not detected right (which at this point is very likely) extract minimal examples with which we can test exactly this one thing and where there isn't anything else in there that is needed.
  • So for example if the jsonpath for the results is not detected correclty, we need a minimal openapi definition with one endpoint and this incorrectly detected object structure as a result, nothing more.
  • Add a new folder in tests/cases for incoming examples and think of some subfolder structure that makes sense to you where you put these examples, you can also add a comment in the openapi file about what does not work, but I will probably be able to figure it out.
  • Put it all on a branch with a PR, then I can have a look how it's going. If you have any questions, ask :)
  • Keep the full openapi spec that you collected also in a separate folder
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants