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

All VCR cassettes are based off of a non-public API #17

Open
jwir3 opened this issue May 4, 2019 · 2 comments
Open

All VCR cassettes are based off of a non-public API #17

jwir3 opened this issue May 4, 2019 · 2 comments
Labels
good first issue Good for newcomers Hacktoberfest An issue we're looking for help on as part of Digital Ocean's annual Hacktoberfest. help wanted Extra attention is needed

Comments

@jwir3
Copy link
Collaborator

jwir3 commented May 4, 2019

Since this originally came out of a project that was private (the Sinking Moon API), we've based all of our API calls on a non-public API. (It's not possible for everyone to access the Sinking Moon API). This means that basically only @jwir3 can recreate the VCR cassettes from scratch.

We should modify this to point to a public API, so that if the need ever arose for others to want to regenerate the API calls in the tests, it can be done.

@jwir3 jwir3 added help wanted Extra attention is needed good first issue Good for newcomers labels May 4, 2019
@jwir3 jwir3 added the Hacktoberfest An issue we're looking for help on as part of Digital Ocean's annual Hacktoberfest. label Oct 3, 2019
@jwir3
Copy link
Collaborator Author

jwir3 commented Oct 17, 2022

Really, what we need to do here is to reorganize all of our specs. It's a complete mess right now. I think a structure like the following might be better:

  • with a single environment
    • based off of http
      • GET
      • POST
      • PATCH
      • PUT
      • HEAD
      • DELETE
    • with multiple environments, one based off of http and one based off of HTTPS
      http`
      • GET (https)
      • POST (https)
      • PATCH (https)
      • PUT (https)
      • HEAD (https)
      • DELETE (https)

This structure would hold for most of our major APIs, then we could test special cases from there in the specifications for config and rest_environment.

@jwir3
Copy link
Collaborator Author

jwir3 commented Oct 17, 2022

Hmm, actually thinking about this more, we have more than that. We have a matrix of options:

  • authenticated vs non-authenticated
  • api-key required vs. non-required
  • http vs https
  • method (GET, POST, PATCH, DELETE, PUT, HEAD)
  • multiple vs. single environments
  • multiple vs. single APIs

We need to somehow form a combination matrix of the ones that can be specified together and come up with a decent structure in code for the specs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers Hacktoberfest An issue we're looking for help on as part of Digital Ocean's annual Hacktoberfest. help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant