Conversation
While it may be the oldest in the run, It's still an example that is generated by the current run, right? If so, I don't see what's the problem with it. This PR seems to solve too many things at once. Please at least separate a PR for |
| require 'json' | ||
| require 'rspec/openapi/schema_cleaner' | ||
|
|
||
| RSpec.describe 'SchemaCleaner' do |
There was a problem hiding this comment.
Can you test it by only adding YAML-level tests at spec/rspec/rails_spec.rb? The only thing that must be maintained in this repository is what OpenAPI schema is generated at each rspec execution, not internal methods to implement it. If you unit-test internal implementations, it becomes harder to refactor the implementation.
So I'm not comfortable having this kind of test when you could just write a test that fails only when needed. This test could fail when it doesn't need to, for example when we rename paths_to_all_fields to something else, which users don't care about. In fact, I actually don't appreciate tests under spec/rspec/schema_merger/ because the interface of RSpec::OpenAPI::SchemaMerger.merge! isn't part of the contact of this gem. Testing the same thing by reading a YAML file generated by running rspec would be more cost-effective because it would fail only when the actual contract is changed.
There was a problem hiding this comment.
I understand your concerns and reasoning.
However, it is unclear for me to write tests that verify item are removed (or preserved) as expected.
IIUC, rspec-openapi read the spec file if it exist, then updates it.
To check item removal, it is required to read the old spec file with outdated items, but the file itself is updated after rails-rspec, so you or future contributors get confused about how to deal with changes in the file.
Any guidance is appreciated
There was a problem hiding this comment.
A simple idea occurred to me.
I will erase unit tests and write rails-rspec-based tests
There was a problem hiding this comment.
I'm okay with having a YAML fixture, like what you did at spec/rspec/schema_merger/*.json, for comparing it against an intermediate result of the schema file. If you have two YAML files for the same spec, initializing the destination path with one of the files, running rspec, and comparing the result with the other file wouldn't be too difficult.
| schema: | ||
| type: string | ||
| example: token | ||
| - name: filter[name] |
There was a problem hiding this comment.
Note) filter[name] was removed because it matched the pattern 3. paths.*.*.parameters
| no_such_field: | ||
| type: string | ||
| example: This field does not exist in rspec |
There was a problem hiding this comment.
Note) no_suche_field was removed because it matched the pattern 7. paths.*.*.responses.*.content.application/json.schema.properties.*
| example: This field does not exist in rspec | ||
| example: | ||
| message: Unauthorized | ||
| post: |
There was a problem hiding this comment.
Note) post was removed because it matched the pattern 2. paths.*.* (HTTP Methods)
| "/no-such-path": | ||
| get: | ||
| summary: no such api | ||
| parameters: [] | ||
| responses: | ||
| '200': | ||
| description: dummy | ||
| content: | ||
| application/json: | ||
| schema: | ||
| type: number | ||
| example: | ||
| - 1 |
There was a problem hiding this comment.
Note) /no-such-path is added but does not appear in theexpected.json because it is removed because of the pattern 1) paths.* (URL paths)
| no_such_field_request: | ||
| type: boolean |
There was a problem hiding this comment.
Note) This is added but does not appear in theexpected.json because it is removed because of the pattern 5) paths.*.*.requestBody.content.application/json.schema.properties.*
| name: k0kubun | ||
| description: description | ||
| database_id: 2 | ||
| no_such_field_request: true |
There was a problem hiding this comment.
Note) This is added but does not appear in theexpected.json because it is removed because of the pattern 4) paths.*.*.requestBody.content.application/json.example.*
| id: 1 | ||
| name: access | ||
| description: logs | ||
| no_such_field_response: true |
There was a problem hiding this comment.
Note) This is added but does not appear in theexpected.json because it is removed because of the pattern 6) paths.*.*.responses.*.content.application/json.example.*
| no_such_field_response: | ||
| type: boolean |
There was a problem hiding this comment.
Note) This is added but does not appear in theexpected.json because it is removed because of the pattern 7) paths.*.*.responses.*.content.application/json.schema.properties.*
|
@k0kubun |
|
I was busy today and didn't get to review this. I'll leave comments when I can. |
| base | ||
| end | ||
|
|
||
| private |
There was a problem hiding this comment.
I think it's better to limit the scope by default, meaning that only #cleanup! should be public.
There was a problem hiding this comment.
Yeah, done in d0c8c8f
Those methods were public for testing, no need to be so now.
|
Looks sensible to me. Now that you've influenced some core parts of this project's design, would you be interested in being a maintainer of this repository and merging this yourself? |
I am happy to join the repo as a maintainer. |
|
Thanks! I invited you to be a collaborator. I'll also make you an owner of the gem on rubygems.org, but for now, I'll wait until you accept the invitation and merge this. |
|
I noticed that you might not have a RubyGems account yet. Could you create one and let me know the username? At least I couldn't find https://rubygems.org/profiles/exoego. |
|
Created exoego in RubyGems with MFA enabled |
|
Perfect 👍 I invited you to be an owner of https://rubygems.org/gems/rspec-openapi. Release instructions
Maintainer expectation
Note that at this moment my capacity is very much saturated. I get GitHub OSS notifications basically everyday and it's already beyond the point where I can handle all of them, likely at least until September. Now that you're a maintainer, please feel free to do anything that you believe is good for this project even when my response is delayed. |
Addresses #55 (comment)
After this PR, some known items (below) will be removed if those exist only in a previous result.
So the removed URLs, parameters or such will be gone automatically.
paths.*URL pathspaths.*.*HTTP Methodspaths.*.*.parameterspaths.*.*.requestBody.content.application/json.example.*paths.*.*.requestBody.content.application/json.schema.properties.*paths.*.*.responses.*.content.application/json.example.*paths.*.*.responses.*.content.application/json.schema.properties.*Other items are preserved even if those exist only in a previous result.
So manually modified items can be retained.
I believe all patterns are covered by fixture-based test in
smartdirectory.Unit tests for internal implementations were removed not to bother refactoring in accordance with #57 (comment)