Change:
```yml tests: <del> - text: The <code>globalTitle</code> variable should not change. testString: assert(globalTitle === "Winter Is Coming"); </del> - text: Your code should not use the <code>replace</code> method for this challenge. testString: assert(!code.match(/.?[sS]*?replace/g)); - text: <code>urlSlug("Winter Is Coming")</code> should return <code>"winter-is-coming"</code>.

Discussion:
<!-- NOTE: If you're reporting a security issue, don't create a GitHub issue. Instead, email We will look into it immediately. --In the exercise, one of the condition is "The globalTitle variable should not change." but it returns an error if you modified the var (for debugging) at the top, even if your function doesn't mutate it. The verification should be that the initial globalTitle variable is the same as the final one, instead of simply looking to match it to a string. Add a Link to the page with the problem:
Hello there, Ideally, I agree, the tests would be robust enough to account for something like this. However, there is usually a reason for the comments, and users should not expect their code to pass, if they ignore this. If others agree to change this, I would not be opposed to the first test being removed. I cannot see it being used in any meaningful way in the seed.
I would argue that, as this lesson comes after the section, users should be somewhat comfortable with using . Changing a global variable's hard-coded value seems like a less practical debugging method than logging a function call with the argument value to debug. Additionally, as mentioned, the is present to indicate which portions of the seed code should not be modified.
for debugging purposes, instead of changing a variable you are told to not change you should change the function call, wiritng there but, yeah, it's a thing that trips many up. But dealing with small details is also something that should be learned
I believe the original purpose of the global variable was to actually pass a variable with a known value () to the function and validate that the function does not mutate it. However, the tests do not even check for this case. Such a test would look like: As states, the user should be writing their own calls to the function to test it, instead of changing the global variable. One way to possibly handle this, would be to remove the global variable declaration and use something similar as I mentioned above: I would argue, this kind of test should be to all the functional programming challenges, since this is one of the main concepts to learn.
I can go ahead and submit a PR if we'd like to go this route.
can a string even be mutated in that way? shouldn't strings be immutable and so that is not possible in any case?

the test should be to make sure the user reference function parameter instead of a global variable even if the global variable is present, I think To see if passed in argument is not mutated should be a thing to check with arrays and objects, as those are mutable
you are correct that strings are immutable, but it is possible to reassign the value of the variable within the function (which is bad practise, thus the reason for the test I believe).
I mean if the global variable is removed from the editor you can't change a global string by operating on function parameter, right?
Correct - if we remove the global variable entirely, then it cannot be modified. If we leave it, it can only be modified by assigning the value to that variable name within the function. However, in general it is bad practise to modify the values of a function's arguments directly - with strings, it is less harmful than it is with arrays, but I believe that was the intent behind this particular test case. !
I should not have used the word "mutable". Looking at the challenge again, I think it would be fine to remove the global variable all together as it is not used in any other test (except the first). So, my suggestion is to remove the declaration and remove the first test, unless someone else can find a good reason to keep them.
I have some errands to run, but can submit a PR later this evening. If anyone else would like to tackle this before then, let me know and I'll gladly step back and give you the opportunity!
I would like to work on this issue, if that's okay with you .
By all means, go ahead! As a note, issues labelled with the "help wanted" tag (like this one) don't require permission before submitting a PR - I only made my earlier comment to ensure my interest didn't deter other contributors. Feel free to let me know if you have any questions!