Skip to content

Update assignments for module rework - #1625

Open
illicitonion wants to merge 2 commits into
mainfrom
reorder-testing-assignments
Open

illicitonion wants to merge 2 commits into
mainfrom
reorder-testing-assignments

Conversation

@illicitonion

Copy link
Copy Markdown
Member

This:

  • Pulls implement-and-rewrite out of the per-sprint folder, and will assign it for sprint 2
  • Updates implement-and-rewrite to use node:test and then rewrite to jest
  • Pulls practice-tdd out of the per-sprint folder, and will assign it to sprint 2
  • Updates everything from require to import
  • Deletes the rest of the Sprint-2 folder because they're unused/unreferenced. We can recover them from git history if we need, but they are no longer relevant to this module.
  • Leaves the rest of Sprint-1 and Sprint-3 in place, but they're not assigned as work anywhere (except Sprint-3/3-dead-code). We can delete these if we think it's confusing - I'm 50:50 on it...

This:
* Pulls implement-and-rewrite out of the per-sprint folder, and will
  assign it for sprint 2
* Updates implement-and-rewrite to use node:test and then rewrite to
  jest
* Pulls practice-tdd out of the per-sprint folder, and will assign it to
  sprint 2
* Updates everything from require to import
* Deletes the rest of the Sprint-2 folder because they're
  unused/unreferenced. We can recover them from git history if we need,
  but they are no longer relevant to this module.
* Leaves the rest of Sprint-1 and Sprint-3 in place, but they're not
  assigned as work anywhere (except Sprint-3/3-dead-code). We can delete
  these if we think it's confusing - I'm 50:50 on it...
@github-actions

This comment has been minimized.

* For `node:test` tests, you can run them in the terminal with `node path/to/file`.
* To run all of the tests in this repo, you can run `npm test`.
* To run just one directory or file of tests, you can run `npm test implement-and-rewrite-tests/rewrite-tests-with-jest` or `implement-and-rewrite-tests/rewrite-tests-with-jest/1-get-angle-type.test.js`.
* VSCode has a built-in test runner that you can use to run the tests, and this should make it much easier to focus on building up your test cases one at a time.

@Liam310 Liam310 Sep 25, 2026 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

VSCode has a built-in test runner...

Not actually built-in AFAIK - I just had to enable a Jest extension in order to have the option for running individual tests appear in the VS Code GUI.

As an aside, I don't personally love this option. It can lead to people exclusively running tests individually and never running them as a whole, which can lead to issues not being caught. Specifically, when someone has accidentally written tests that are not independent but hasn't seen that play out because they've only run them in isolation. What do you think?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Not actually built-in AFAIK - I just had to enable a Jest extension in order to use VS Code's GUI to run the tests rather than the command line.

Can you suggest an edit to discuss installing/enabling the extension? :)

As an aside, I don't personally love this option. It can lead to people exclusively running tests individually and never running them as a whole, which can lead to issues if someone has not made their tests independent without realising that could be a problem. What do you think?

Let's maybe add a prep item about this, where we can give a sample repo and show people the trade-offs/limitations here?

There's a tricky balance thing here where because the project is whole-repo-scoped, if you just npm test you end up running (and failing) the tests from all of the exercises you haven't actually done. So realistically in this repo the two options are npm test path/to/dir (fiddly to type, or to switch tests) or using the in-IDE integration (with the issues you raise)...

@Liam310

Liam310 commented Sep 25, 2026 •

Copy link
Copy Markdown
Contributor

Looks good! To respond to some of your overall points:

Deletes the rest of the Sprint-2 folder because they're unused/unreferenced. We can recover them from git history if we need, but they are no longer relevant to this module.

This is fine, I think in an ideal world we'd have an archive of tasks we don't use any more, because whilst they are technically still available in git history, it'd be very easy to forget that they exist entirely and awkward to search for them if we do remember. I would say leave them as is here (deleted) and I'll add "create archive" to my to-do list 🙂

Leaves the rest of Sprint-1 and Sprint-3 in place, but they're not assigned as work anywhere (except Sprint-3/3-dead-code). We can delete these if we think it's confusing - I'm 50:50 on it...

Sprint-1 can be removed completely - its contents are now Sprint-2 JS Fundamentals. As for Sprint-3, it looks like like both 3-dead-code and 4-stretch are assigned as coursework in the portal, so I would leave the content in but be inclined to take the same approach you've taken above, and pull them out of the Sprint-3 folder and just have two root-level folders called dead-code and stretch.

Let me know what you think!

rm -rf Sprint-1
mv Sprint-3/3-dead-code dead-code
mv Sprint-3/4-stretch sprint-3-stretch-exercises
@illicitonion

Copy link
Copy Markdown
Member Author

Looks good! To respond to some of your overall points:

Deletes the rest of the Sprint-2 folder because they're unused/unreferenced. We can recover them from git history if we need, but they are no longer relevant to this module.

This is fine, I think in an ideal world we'd have an archive of tasks we don't use any more, because whilst they are technically still available in git history, it'd be very easy to forget that they exist entirely and awkward to search for them if we do remember. I would say leave them as is here (deleted) and I'll add "create archive" to my to-do list 🙂

Thanks! 👍

Leaves the rest of Sprint-1 and Sprint-3 in place, but they're not assigned as work anywhere (except Sprint-3/3-dead-code). We can delete these if we think it's confusing - I'm 50:50 on it...

Sprint-1 can be removed completely - its contents are now Sprint-2 JS Fundamentals. As for Sprint-3, it looks like like both 3-dead-code and 4-stretch are assigned as coursework in the portal, so I would leave the content in but be inclined to take the same approach you've taken above, and pull them out of the Sprint-3 folder and just have two root-level folders called dead-code and stretch.

Let me know what you think!

Makes sense - done! I moved stretch to sprint-3-stretch-exercises because I think realistically if we end up with more stretch exercises we probably want to group them somehow.

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.

2 participants