This repository was archived by the owner on Jan 14, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 283
isolate tests in exercise #260
Open
shieldo
wants to merge
2
commits into
CodeYourFuture:main
Choose a base branch
from
shieldo:isolate_tests
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about doing instead
This would cause the trainee receiving a
object is not extensible
exception in case they accidentally try to push values into this constant.(note I come from ruby where it is usually expected to explicitly freeze constants so they become inmutable, not sure if this is as well known in the JS world or not)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this feedback!
I think I'm against this for two reasons:
I'm making the argument here to make mutability not a problem at this stage (so as to not overload the exercise) - tests like this should be isolated because the order in which they execute is non-deterministic, so this situation has arisen out of bad practice. It's reasonable that mutations are commented on I think in code review, but not reasonable that they make code fail with an error that assumes a lot of knowledge for this stage
I'd argue that tests should always be reasonably legible to trainees at whatever level of the course they are at, and referencing the
Object
class I'd argue is premature. If trainees were to look upObject.freeze
and understand what it did, I'm not sure that the reason for using it here would be clear.I wasn't aware of
Object.freeze
in JavaScript, actually, and am used to calling.freeze
on objects in Ruby that are constants! The equivalent thing to do here I think would be to freeze the array on assigning it toARTICLE_TITLES
, but I'm not convinced it's the right approach.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we should teach the trainees that mutability is usually not accepted, even if not explicitly stated on the exercise level at least in the tests - the tests should explicitly check that the array that was sent in remained unchanged. If any trainees gets blocked by this they could always ask. On the other hand if they send in a solution which does change the input and no one tells them that's usually not acepatable they could get lost later. I actually did receive a couple questions related on this on why they needed to create a new array in these solutions, although they could just change the parameter in one of the week2 solutions (https://github.com/CodeYourFuture/JavaScript-Core-1-Coursework-Week2-Solution/blob/main/mandatory/2-function-creation.js#L81 ) which was a good question on multiple fronts (immutability, variable assignments, difference between changing an object and assigning a new value to a variable, etc)
On point 2, that could always be solved with a simple comment, like
// make sure that the list of article can not be accidentally changed
. But as you mentioned freeze is not as known in JS land, so I'm happy to swap it's usage to explicit checks that the functions created are pure and don't have side effects