feat: Build changelog for AsyncAPI specifications#70
feat: Build changelog for AsyncAPI specifications#70makeev-pavel wants to merge 31 commits intodevelopfrom
Conversation
b41ex
left a comment
b41ex
left a comment
There was a problem hiding this comment.
As discussed, let's add following group of tests:
BWC scopes
Change deduplication
- changes in shared entities
- different scopes
- in the same specification
- across different specifications
…elog' into feature/asyncapi-basic-e2e-changelog
test/projects/asyncapi-changes/channel/add-message-with-multiple-operations/after.yaml
Show resolved
Hide resolved
test/asyncapi-apikind.test.ts
Outdated
| it.each([ | ||
| // default | before | after | expected | ||
| ['bwc', 'undefined', 'undefined', undefined], | ||
| ['bwc', 'undefined', 'bwc', undefined], |
There was a problem hiding this comment.
undefined as ER for cases where one of the value is undefined and another is bwc (or even worse- both are bwc, but the ER is undefined) looks counter-intuitive to me. I would say that in these cases the function should return bwc.
test/asyncapi-apikind.test.ts
Outdated
| it.each([ | ||
| // default | before | after | expected | ||
| ['bwc', 'undefined', 'undefined', undefined], | ||
| ['bwc', 'undefined', 'bwc', undefined], |
There was a problem hiding this comment.
Ditto regarding ER undefined for cases
undefined,bwcbwc,undefinedbwc,bwc
| @@ -25,68 +32,228 @@ describe('AsyncAPI apiKind calculation', () => { | |||
| expect(result).toBe(expected) | |||
| }) | |||
| }) | |||
|
|
|||
| describe('Changelog backward compatibility scope function', () => { | |||
There was a problem hiding this comment.
Integration tests are missing for the apiKind handling during changelog build.
Integration tests are important here, because final result depends on behavior of both compatibility scope function provided by api-processor and behavior of api-diff.
Review corresponding integration tests for REST at least in these test groups and add analogous tests for Async.
'ApiKind operations section tests'
'Priority operation ApiKind and default ApiKind'
'Remove operations tests'
There is actually less places where we could set api kind in Async compared to REST, so number of tests for Async will be less than number of tests for REST, but cases we need to check are all similar.
There was a problem hiding this comment.
Added integration tests for AsyncAPI x-api-kind handling in asyncapi-changelog-apikind.test.ts, analogous to the REST tests in apiKinds.test.ts.
Operation-level x-api-kind (9 cases, table-driven via test.each):
All transitions between none, BWC, and no-BWC in prev/curr documents — verifies that no-BWC in either document results in risky classification, and BWC (or default) results in breaking.
Channel-level x-api-kind (9 cases, same table reused):
Same transition matrix applied at channel level.
Operation + Channel priority (4 cases):
- Fallback: operation without x-api-kind inherits from channel (channel-bwc-operation-none, channel-nobwc-operation-none)
- Override: operation x-api-kind takes priority over channel (channel-bwc-operation-nobwc, channel-nobwc-operation-bwc)
Remove operation (7 cases):
- Removed operation with x-api-kind: BWC → breaking
- Removed operation with x-api-kind: no-BWC → risky
- Removed operation without x-api-kind → breaking (default BWC)
- Priority: operation x-api-kind overrides channel on removal (remove-channel-nobwc-operation-bwc, remove-channel-bwc-operation-nobwc)
- Fallback: removed operation without x-api-kind uses channel (remove-channel-nobwc-operation-none, remove-channel-bwc-operation-none)
Note on "add operation": not covered because adding an operation is classified as non-breaking by api-diff regardless of x-api-kind — same as in REST tests (apiKinds.test.ts).
3 participants
No description provided.