-
Notifications
You must be signed in to change notification settings - Fork 227
apiviewgo supports tree tokens #9409
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
Conversation
RickWinter
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any coverage data or apiview scenario coverage data?
We can generate coverage for unit tests but that's statement coverage (currently 89.3%), not useful here because there are so many conditions. We can validate our output against the JSON schema (have done) but there's no scenario coverage a la codegen, I guess because there's no consistency in input (source code) across parsers. I suppose someone could write language-agnostic tests validating JSON details like "all LineId values are unique" and "all NavigateToId values are also LineId values". @praveenkuttappan, what do you think? |
We already have tests in APIView that covers language independent JSON validation for all scenarios in both UI and server side. But it will still be better to have some tests in the parser to ensure basic test cases that json is generated as expected from parser. One basic validation you can add in parser side is to ensure generated json is as per the JSON schema. |
Closes #8654. Examples of the new format: azblob, azcore
I fixed a bug in today's parser that creates duplicate types for aliases, however this PR doesn't address other bugs or feature gaps. I haven't found anything newly broken by this PR.
This PR also closes #3142 by adding a new test that generates JSON output and fails when that changes.