Test Coverage Gaps: Request Layer, API Methods, and Beyond #98
Replies: 4 comments
-
|
Result receiver tests are done in #99. All five receiver types (DeletedResultReceiver, BoolResultReceiver, ResultReceiver[A], PaginatedResultReceiver[A], SearchResultReceiver[A]) now have coverage for success, failure, and converter-error paths — 14 tests total. |
Beta Was this translation helpful? Give feedback.
-
|
"High Level API" tests are done in #100 |
Beta Was this translation helpful? Give feedback.
-
|
Completed by #101. |
Beta Was this translation helpful? Give feedback.
-
|
The remaining gap — search and pagination behavior tests — has been implemented in #102. What's covered:
This covers both |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The JSON converter and utility tests from the original analysis are now implemented. This discussion covers what's still untested.
HTTP request actors
None of the request actors have any test coverage:
JsonRequester— GET/POST/PATCH with JSON response parsing. Untested: correct URL construction, header setting (auth, content-type), response body parsing, HTTP error status handling.LinkedJsonRequester— Follows pagination links. Untested: Link header parsing into follow-up requests, redirect handling (301, 307), terminal page behavior.NoContentRequester— DELETE/PUT expecting 204. Untested: success on 204, failure on other status codes, response body ignored.CheckRequester— Status-based boolean (204=true, 404=false). Untested: both branches, unexpected status codes.These are actors that do real HTTP, so testing them requires either mock HTTP servers or an abstraction boundary that can be substituted in tests.
High-level API methods
No methods on
GitHub,Repository,Issue,Gist,PullRequest, orGistCommentare tested. This includes:GitHub:get_repo(),get_gist(),create_gist(),get_user_gists(),get_public_gists(),search_issues(),get_org_repos()Repository:create_label(),delete_label(),create_release(),get_commit(),get_issue(),get_issues(),get_pull_request()Issue:create_comment(),get_comments()PullRequest:get_files()Gist:update_gist(),delete_gist(),get_revision(),fork(),get_forks(),get_commits(),star(),unstar(),is_starred(),create_comment(),get_comments()GistComment:update(),delete()These methods construct URLs, set query parameters, and wire up result receivers. Testing them would verify correct URL construction and parameter passing without necessarily hitting the network — if the request layer were abstractable.
Result receivers
ResultReceiver[A],PaginatedResultReceiver[A],SearchResultReceiver[A],DeletedResultReceiver, andBoolResultReceiverare all untested. These handle the callback from request actors to user code.Authentication
Credentialsclass and bearer token header construction are untested. Worth verifying theAuthorization: Bearer <token>header is set correctly.Search and pagination
SearchResults[A]pagination (prev/next page navigation) andSearchIssuesrequest building are untested. The pagination link extraction is tested, but the pagination behavior (making follow-up requests) is not.SSL
SSLContextFactoryhas no tests. Low priority since it's thin wrapper code, but worth noting.Architectural barrier
The biggest barrier to testing the remaining code is that the request actors (
JsonRequester, etc.) make real HTTP calls with no substitution point. Testing the high-level API methods and result receivers likely requires either:VCSBuilder)The JSON converter tests cover the data layer thoroughly. Everything above it — request construction, HTTP execution, response routing, and the public API surface — is currently untested.
Beta Was this translation helpful? Give feedback.
All reactions