Code change:
Link to the challenge: Adding a global flag to the regular expression has the test fail for the first two assertions. This can be confusing considering also how the challenge is introduced, since the code snippet explaining the concept shows the global flag being used. Update the code snippet introducing the challenge: However, since the global flag should not affect the outcome of the test (to what I can ascertain), a better suggestion would be to update the test itself, to account for its presence.
Thanks for the detailed report! I think it would make sense to do both. The isn't necessary, so it should not be there and it's not wrong, so we should not reject it.
It might be better to remove the global flag from the challenge example unless we also explain how and give some info on . I think in order to really know if we should fail the test when using the global flag we would have to consider how the code is supposed to run. Are we "emulating" that each is being run in isolation or are they executed one after the other.
Agreed. This challenge focuses on teaching the user about groups - the use of over seem incidental to me, as does the presence of the flag. Also, the challenge asks you to make sure so it's only asking you to use against once.
But it is when the test is called multiple times on the same regex. Isn't this kind of the same as when users use global variables which end up causing the user's code to fail for all tests except the first because the the global variable does not get reset each time?
I'm dumb - I'd completely failed to realise it's being run twice, once in the user's code and again in the tests. You're quite right and PR fixes that.
Challenge: Fails with: Passes with:
The example/seed code moves to 14. I guess one easy option would be to change the example string to something like "Fun with regular expressions!", that should let all the tests pass and accept the global flag. The problem is if the camper uses a different string to test the regex it may fail. So we might just have to reset before running the tests.
I assumed it would be the exact same fix as what Tom did:
yep, that's what I concluded. I think we can apply Tom's fix in , rather than modifying the tests. Either works, but that should be more concise.

Related discussion:
text: ```yml tests: - text: Your regex <code>myRegex</code> should return <code>true</code> for the string <code>Franklin D. Roosevelt</code> <del> testString: assert(myRegex.test('Franklin D. Roosevelt')); </del> <ins> testString: myRegex.lastIndex = 0; assert(myRegex.test('Franklin D. Roosevelt')); </ins> - text: Your regex <code>myRegex</code> should return <code>true</code> for the string <code>Eleanor Roosevelt</code> <del> testString: assert(myRegex.test('Eleanor Roosevelt')); </del> <ins> testString: myRegex.lastIndex = 0; assert(myRegex.test('Eleanor Roosevelt')); </ins> - text: Your regex <code>myRegex</code> should return <code>false</code> for the string <code>Franklin Rosevelt</code> <del> testString: assert(!myRegex.test('Franklin Rosevelt')); </del> <ins> testString: myRegex.lastIndex = 0; assert(!myRegex.test('Franklin Rosevelt')); </ins> - text: You should use <code>.test()</code> to test the regex. testString: assert(code.match(/myRegex.test(s*myStrings*)/)); - text: Your result should return <code>true</code>.