[repo-assist] test: OperationCompiler response-type tests for component $ref and array responses (+5 tests, 468→473)#450
Conversation
…d array responses (+5 tests, 468->473) - GET returning $ref to component schema: verifies return type is Task<ComponentType>, not Task<unit>, and that the referenced schema is compiled as a named type with its properties - GET returning array-of-$ref: verifies return type is Task<ComponentType[]> and element type name - POST with 201 $ref response: verifies return type is Task<ComponentType> (not Task<unit>) and that the request body parameter type is the NewPet component schema type These tests cover the important cross-compiler interaction where OperationCompiler consumes component schemas that DefinitionCompiler compiled, verifying the return-type threading works. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Adds additional unit-test coverage in Schema.OperationCompilationTests to validate that OperationCompiler correctly threads response schemas that are $ref’d component types (including arrays and 201-created responses) into generated Task<...> method return types and request-body parameter types.
Changes:
- Added tests for GET responses returning a single component
$ref(Task<Pet>) and array-of-$ref(Task<Pet[]>). - Added tests for POST with a
201response using a$refbody (Task<Pet>) and request body$refparameter (NewPet).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@copilot address inline comments |
Agent-Logs-Url: https://github.com/fsprojects/SwaggerProvider/sessions/fd70389a-5f2b-4fc1-a4ca-cea6dba66958 Co-authored-by: sergey-tihon <1197905+sergey-tihon@users.noreply.github.com>
Addressed the inline review comments in commit Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
@copilot fix link |
|
@copilot fix the build, format code |
Co-authored-by: sergey-tihon <1197905+sergey-tihon@users.noreply.github.com>
Done in Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
Agent-Logs-Url: https://github.com/fsprojects/SwaggerProvider/sessions/9ccb48a2-4fb6-4a97-b715-eb0f9efed006 Co-authored-by: sergey-tihon <1197905+sergey-tihon@users.noreply.github.com>
🤖 This PR was created by Repo Assist, an automated AI assistant.
Summary
Adds 8 new
[<Fact>]tests (5 net new test cases in the runner) covering the interaction betweenDefinitionCompilerandOperationCompilerwhen response schemas use$refto component types.What's tested
GET returning a single component
$ref(/pets/{id}→Task<Pet>):Task<T>where T is the compiledPetProvidedType (notTask<unit>orTask<string>)Petschema is compiled as a named typePettype has its declared propertiesGET returning array-of-
$ref(/pets→Task<Pet[]>):Task<T[]>(array return type)POST with
201response using$ref(createPet→Task<Pet>):Task<unit>)NewPetcomponent schema typeWhy this matters
Existing tests (e.g. the PUT endpoint test) only check that the return type is not
unit. They do not verify that the return type is the specific component schema that was referenced. These new tests close that gap and provide confidence that the type threading betweenDefinitionCompilerandOperationCompilerworks correctly for common real-world API patterns (single resource GET, collection GET, POST-and-return).Test Status
All 473 tests pass (468 before → 473 after).