CW-054 · Measure the counts the gate only declares
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 68/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- github-actions, typescript
- Domain
- ci-cd, testing-qa
Research direction
Start with backend/scripts/verify-doc-counts.ts to understand how domain and backend counts are measured, then inspect the web, mobile, and e2e jobs in .github/workflows/ci.yml. Choose one of the stated approaches and verify that adding a test without changing the declared count fails CI for e2e, web, and mobile.
Written by the indexing model from the issue text.
Description
Priority P2 · Area platform · Estimate S · 🌱 good first issue
What to build
npm run verify:docs exists, in its own words, because "counts in prose are the one claim nothing else checks." It measures two of the five: domain tests and backend unit tests are counted by running the suites. The web, mobile and e2e counts are typed into the script by hand, and the gate checks the prose against the typed number — never against the suites.
So it drifts exactly the way it was written to prevent. The declared e2e count stood at 211 while main ran 224: thirteen checks landed across three tickets and CI stayed green throughout. It surfaced only because a security fix added three more and someone counted by hand.
Measure e2e the way the unit suites are already measured — or have the e2e job assert its own total against the declared figure, and the same for web and mobile in their jobs. Either way, no count in the gate should be a number somebody has to remember to change.
Acceptance criteria
- Adding an e2e test without touching the declared count fails CI.
- The same holds for web and for mobile.
Blocked by
None (can start immediately).
Files backend/scripts/verify-doc-counts.ts, .github/workflows/ci.yml
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 37m
- Merged PRs (30d)
- 1
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SuruchBoss/Cwork
-
documentation good first issue P3 phase-E
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
SuruchBoss/Cwork#50 ·
-
good first issue mobile P2
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SuruchBoss/Cwork#11 ·
-
P1 payroll phase-3
Difficulty 5/5 Over a week Newbie friendliness 30/100
SuruchBoss/Cwork#59 ·
-
P2 phase-3
Difficulty 5/5 Over a week Newbie friendliness 45/100
SuruchBoss/Cwork#58 ·
-
P3 project
Difficulty 3/5 1-2 days Newbie friendliness 76/100
SuruchBoss/Cwork#56 ·
All issues in SuruchBoss/Cwork
Similar issues
-
refactor
Difficulty 2/5 Half a day Newbie friendliness 84/100
Maintainers usually reply within 5 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
OHDSI/Data2Evidence#3450 ·
Maintainers usually reply within 2 days
-
e2e-failure ready-to-code
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
redhat-developer/rhdh-plugin-export-overlays#4011 · 1 comment ·
Maintainers usually reply within 1 day
-
automation missing-model model-sync provider:ofox
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
anomalyco/models.dev#8421 ·
Maintainers usually reply within 1 day
-
SlackAdapter and TelegramAdapter are not assignable to Adapter under exactOptionalPropertyTypesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day