Change:
```yml tests: - text: Your code should use bracket and dot notation to access the proper code name, and print "Loki" to the console. <del> testString: assert(code.match(/(?:json[2].codeNames[1]|json[2][('|")codeNames1][1])/g)); </del> <ins> testString: assert(code.match(/consoles*.s*logs*(s*jsons*[2]s*(.s*codeNames|[s*('|`|")codeNames2s*])s*[s*1s*]s*)/g)); </ins> ```

Discussion:
Not all of the challenges listed in were fixed by . This issue is for the remaining challenges that the aforementioned PR did not modify. The tests for various challenges are too strict about line breaks before method calls. E.g. something like this passes: But this causes the tests to fail: :: Browser Name: Firefox Developer Edition Browser Version: 66.0b9 Operating System: Antergos Linux
I am looking into it
Hi Randel, Do you think something like would help? My concern is, that it would remove spaces in actual strings (if any inside of the code). Shall we move in this direction (means ) or different?
Yes, that is more like what I am thinking. You have valid concerns concerning removing spaces in actual strings. In challenges that do not have specific code strings in the element, we should be fine, so for these specific challenges we could maybe use a helper function like: Then we could use it in the like the following for the or better yet, move the helper function into a special within the with id="html-teardown" like: html <scriptwindow.removeWhiteSpace = str =str.replace(/s/g, ''); </script` and then the test would look cleaner: Lastly, most of the challenges are missing a valid full working solution in the section of the challenge file. The solutions are used to validate the tests still allow a valid solution to pass.
Shall I create PR with changes based on your suggestion for these two specific challenges? Shall we consider to apply the same fix for other challenges? Do you think putting a helper function into section is robust enough at the current moment?
After thinking even more about this, I am going to check with a few other collaborators to see if we already have access to a minifier library we could use instead. If that is the case, then I will let you know how we can use it instead. Then we would not have to worry about accidentally removing white space from code which actually needs to be a part of a string or something. Again, this is not an issue for these particular challenges, but I would rather use something that could be a model for how to best write tests for these types of challenges in the future. Give me a day to get back with you.
I agree. Thanks for the updates.

Looking forward to hearing from you
I have asked who has a very solid understanding of what helper utilities to which we have access.
Any updates on this or shall we use approach described above?
We have concluded for now, we will have to write our own as they do not want to add another package to the library. I think we should actually consider how we can test these types of challenges without resorting to using regex. For example, we should be validating that the code written actual returns the correct JSON response. That is the true test. We might look for a few key methods with regex, but not complete lines of code.