Skip to content

Add missing parser test coverage - #7

Open
AadhilFarhan wants to merge 1 commit into
mainfrom
test/parser-coverage-gaps
Open

Add missing parser test coverage#7
AadhilFarhan wants to merge 1 commit into
mainfrom
test/parser-coverage-gaps

Conversation

@AadhilFarhan

Copy link
Copy Markdown
Owner

What

Coverage gaps flagged by review, none of them tied to a specific behavior change (this PR adds tests only, no source changes):

  • PsCommParser.parse and PortScanner.parseCwds had zero tests despite being real parsers with their own line formats.
  • Classifier.framework only exercised 7 of 27 non-.unknown Framework cases. Added the remaining 21.
  • ProjectNamer's two documented positive fallback paths (folder name when a manifest file exists; folder name when a project file like .xcodeproj exists) were untested — only the package.json-success and rejection paths had coverage.

A note on the Classifier tests specifically

This same review is landing a separate PR (fix/classifier-false-positives) that changes single-word marker matching from raw substring to token/basename-boundary matching. I deliberately wrote every new framework-detection test case so the marker appears as its own clean token (e.g. node node_modules/.bin/nuxt dev, never something like nuxt-experiments/server.js that only matches under substring semantics) — so these tests pass identically regardless of which of the two PRs merges first, and don't need any rework afterward.

Test plan

  • All 22 new Classifier.framework assertions pass individually (isolated with swift test --filter ClassifierTests, not just trusted from the aggregate count).
  • Full suite: 17/17 passing.

- PsCommParser and PortScanner.parseCwds had zero tests.
- Classifier.framework only exercised 7 of 27 non-.unknown Framework
  cases. Added the remaining 21, using invocations where each marker
  appears as its own clean token (never embedded in a longer word),
  so these pass identically under both the current substring-matching
  implementation and the token/basename-boundary matching this same
  review is landing in a separate PR.
- ProjectNamer's two documented positive paths — falling back to the
  folder name when a manifest file or a project file (.xcodeproj etc.)
  is present — were untested; only the package.json and rejection
  paths had coverage.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant