worldline / worldline/devview

test: cover the gaps left by the audit

Open
#91 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

stale test
Dominant language
Kotlin
Stars
10
Forks
2
Avg merge
2d 14h
Merged PRs (30d)
13

Description

Summary

A grab-bag of test coverage gaps identified while auditing the networkmock family, independent of the OpenAPI migration (tracked in the epic, #72). Each bullet below is independently addressable — feel free to split into separate PRs (or separate issues) rather than doing all of them at once; this issue exists to record them so they aren't lost, not to mandate one big PR.

Gaps

  1. Delay precedenceOperation.delayMs ?: group.defaultDelayMs resolution (devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/repository/MockConfigRepository.kt:366) has no dedicated test asserting the precedence order (operation-level delay wins, falls back to group default, falls back to no delay).
  2. Ambiguous-match precedence — if two groups' configured hosts both match an incoming request's hostname, findMatchingMock (repository/MockConfigRepository.kt:304-374) returns whichever is declared first, with no test pinning this down. (If #2 has landed by the time this is picked up, this is likely already covered there — check before duplicating.)
  3. NetworkMockEndpointScreen has zero tests — no coverage exists for the sticky-header status-family grouping (devview-networkmock/src/commonMain/kotlin/com/worldline/devview/networkmock/NetworkMockEndpointScreen.kt:119-121, :234-278), the "No mock" row (:208-225), or response-row selection (:244-262).
  4. Preview/diff bottom sheet has zero testsNetworkMockEndpointPreviewBottomSheet.kt and the diff rendering pipeline it drives (utils/DiffLineUtils.kt) have no test coverage, despite PreviewSheetState itself (the state machine) being tested in PreviewSheetStateTest.kt.
  5. No test loads the real sample mocks.json (or, post-migration, the real sample spec) — every existing config-loading test uses hand-built fixture data (MockTestData.kt), so the shipped sample can silently drift out of sync with what the parser actually accepts. Add a test that loads sample/network/src/commonMain/composeResources/files/networkmocks/mocks.json (or its post-migration equivalent) through the real repository and asserts it parses successfully.
  6. queryParams/queryParameters matching through the Ktor pluginRequestMatcherTest.kt covers matchesQueryParams in isolation thoroughly, but NetworkMockPluginTest.kt (devview-networkmock-ktor/src/androidHostTest/...) has no end-to-end test exercising query-param matching through the actual plugin interception path.
  7. No assertion on response headers/content-type in NetworkMockPluginTest.kt — existing tests check status and body but not that Content-Type: application/json is actually present on the synthetic response.

Acceptance criteria

  • Each gap above has at least one new test closing it, or is explicitly noted as already covered by a different in-flight PR (to avoid duplicate work — check the epic #72 for what's landed).
  • New tests follow this repo's existing conventions: commonTest + JVM for repository/matcher logic (see RequestMatcherTest.kt, MockConfigRepositoryTest.kt for style), androidDeviceTest + fakes for Compose UI (see EndpointCardTest.kt for style), androidHostTest + MockK for the Ktor plugin (see NetworkMockPluginTest.kt for style).

Files likely touched

  • devview-networkmock-core/src/commonTest/kotlin/com/worldline/devview/networkmock/core/repository/MockConfigRepositoryTest.kt
  • devview-networkmock/src/androidDeviceTest/kotlin/com/worldline/devview/networkmock/... (new test files for the endpoint screen and preview sheet)
  • devview-networkmock-ktor/src/androidHostTest/kotlin/com/worldline/devview/networkmock/ktor/plugin/NetworkMockPluginTest.kt

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with MockConfigRepositoryTest.kt, RequestMatcherTest.kt, NetworkMockPluginTest.kt, and EndpointCardTest.kt to follow the repository's commonTest, androidDeviceTest, and androidHostTest conventions. Check epic #72 before duplicating coverage, then add focused tests for the listed repository, UI, sample-config, and plugin gaps. Done means each gap is covered or explicitly recorded as already covered.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, kotlin
Domain
testing
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.