Open chlowell opened 5 days ago
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?
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.