Skip to content

Conversation

@wheresdiasd
Copy link

@wheresdiasd wheresdiasd commented Nov 8, 2025

The pull requests consist in adding coverage for the sprint-3 coursework "IMPLEMENT AND REWRITE".

When users open a PR with the pattern 'coursework/sprint-3-implement-and-rewrite from their forks, it should run the expected tests for the coursework scenarios in a way the Reviewer have a smooth perspective of the written test results.

In addition, introduces a shell script that compares the implementation with the test cases to see if their match in equality of test cases.

The summary looks like below

Screenshot 2025-11-20 at 07 10 38

And that is how the checks tab look like where we can see if the tests are actually passing or not.
Screenshot 2025-11-27 at 10 47 48

@github-actions
Copy link

github-actions bot commented Nov 8, 2025

Your PR's title isn't in the expected format.

Please check the expected title format, and update yours to match.

Reason: Wrong number of parts separated by |s

If this PR is not coursework, please add the NotCoursework label (and message on Slack in #cyf-curriculum or it will probably not be noticed).

i786m and others added 18 commits November 8, 2025 09:12
- Add Jest coverage configuration with 100% threshold
- Create inline test verification script that:
  - Runs inline assertion tests with Node.js
  - Detects console.assert failures
  - Verifies test parity between inline and Jest tests
  - Reports disparities in both directions
- Add GitHub Actions workflow that:
  - Triggers on coursework/sprint-3-implement-and-rewrite* branches
  - Runs inline tests with parity check
  - Runs Jest tests with coverage
  - Generates coverage report on PRs
- Set branches, lines, statements to 40%
- Keep functions at 100% to ensure every function is tested
- More practical for educational purposes while ensuring core functionality is covered
- Remove ArtiomTr/jest-coverage-report-action (was failing)
- Add simple coverage summary to GitHub Actions summary
- Upload coverage artifacts with if: always() to ensure they're saved even on failure
- Add inline test results table to summary (passed/failed counts)
- Add test parity comparison table showing mismatches
- Generate HTML coverage reports for download
- Parse and display coverage metrics in summary with threshold checks
- Visual status indicators (✅/❌) for all metrics
- Clear instructions to download HTML coverage report artifact
- Replace custom parsing with maintained jest-coverage-comment action
- Displays coverage badge, summary table, and file-by-file coverage
- Shows in both PR comments and GitHub Actions summary
- More reliable than manual JSON parsing
- Add peaceiris/actions-gh-pages to deploy HTML reports
- Coverage reports accessible at github.io URL per branch
- Add coverage report link to GitHub Actions summary
- No need to download artifacts, view directly in browser
- Remove GitHub Pages deployment
- Remove MishaKav/jest-coverage-comment
- Let ArtiomTr action run tests and generate coverage itself
- Simpler workflow with just inline tests + ArtiomTr coverage report
- Run Jest with required flags: --coverage --ci --json --testLocationInResults --outputFile=report.json
- Pass report.json to ArtiomTr action via coverage-file parameter
- Matches the documented example from ArtiomTr/jest-coverage-report-action
- Add pull-requests: write permission to allow action to comment on PRs
- ArtiomTr action will now automatically post coverage reports as PR comments
- Comments will include coverage summary and file-by-file breakdown
- Remove pull-requests: write permission
- Coverage report will only show in GitHub Actions Summary
- Avoids permission issues when forking to upstream repos
@wheresdiasd wheresdiasd force-pushed the refactor/implement-rewrite-coverage branch from 0cccc97 to 003b0ec Compare November 8, 2025 12:12
@wheresdiasd wheresdiasd force-pushed the refactor/implement-rewrite-coverage branch from 57372bb to 4c72c29 Compare November 20, 2025 08:55
@github-actions
Copy link

Your PR's title isn't in the expected format.

Please check the expected title format, and update yours to match.

Reason: Wrong number of parts separated by |s

If this PR is not coursework, please add the NotCoursework label (and message on Slack in #cyf-curriculum or it will probably not be noticed).

If this PR needs reviewed, please add the 'Needs Review' label to this PR after you have resolved the issues listed above.

@wheresdiasd wheresdiasd reopened this Nov 20, 2025
@github-actions
Copy link

Your PR's title isn't in the expected format.

Please check the expected title format, and update yours to match.

Reason: Wrong number of parts separated by |s

If this PR is not coursework, please add the NotCoursework label (and message on Slack in #cyf-curriculum or it will probably not be noticed).

If this PR needs reviewed, please add the 'Needs Review' label to this PR after you have resolved the issues listed above.

@github-actions
Copy link

Your PR's title isn't in the expected format.

Please check the expected title format, and update yours to match.

Reason: Wrong number of parts separated by |s

If this PR is not coursework, please add the NotCoursework label (and message on Slack in #cyf-curriculum or it will probably not be noticed).

If this PR needs reviewed, please add the 'Needs Review' label to this PR after you have resolved the issues listed above.

@github-actions
Copy link

Your PR's title isn't in the expected format.

Please check the expected title format, and update yours to match.

Reason: Wrong number of parts separated by |s

If this PR is not coursework, please add the NotCoursework label (and message on Slack in #cyf-curriculum or it will probably not be noticed).

If this PR needs reviewed, please add the 'Needs Review' label to this PR after you have resolved the issues listed above.

Copy link

@LonMcGregor LonMcGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, This is a good idea that helps reviewers verify trainees are doing the task, and could help to visualise why we are getting trainees to practice rewriting tests to use a framework.

It looks like you have changed the reference files that trainees will start working on in the Sprint-3 directory. How much of that is intended to be committed back to main?

I am looking at the sample output here: https://github.com/CodeYourFuture/Module-Structuring-and-Testing-Data/actions/runs/19738349167

I have some thoughts:

  1. Is there an easier way for trainees to see this output? Currently it exists in the "checks" tab, but I don't see any obvious means of directing the trainee / reviewer towards this output, other than some comments in the README.
  2. Can trainees run this in vs code / local CLI, as the README suggests for jest on its own, so they can avoid pushing a failing PR? Could instructions be added to that effect ?
  3. Are the tables going to be clear enough to read. I.e. are terms like "Inline Assertion Tests" and "Test Parity Check" understandable enough for trainees that may be brand new to the concept of testing?
  4. Following from the two points above, Is there some way we could make a comment under a PR appear with a clear explanation of what needs to be changed to make it pass? This would be in line with how automated PR checks currently work.
  5. In the linked run, the test finds issues, but github is recording the test as having passed. that should probably be fixed so it shows a cross. This might surface issues better in the github UI.

Extra question about the learning:
Do you know if currently the concept of github / CI test output is covered in a general sense, or is this the trainees first introduction to it? Does the prep for this sprint give enough background for them to understand this new kind of PR submission?

continue-on-error: true

- name: Run Jest Tests with Coverage
run: npx jest --config=jest.config.jest-tests.js --coverage --ci

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the npm test command is defined in the package.json.Is there a reason you use npx to run the same command here?

coveragePathIgnorePatterns: [
"/node_modules/",
],
coverageReporters: ["text", "lcov", "json-summary", "html"],

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we reduce the coverageReporters here, or do we need all of them?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file looks the same as for coverage-2. Could they be combined?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test coverage runs for task 2 and task 3 in this sprint. Either the instructions should be replicated in those readmes, or a more general set of instructions should be given in the main sprint3 readme rather than here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants