Const FCC declared but not recognised by UI

Tell us what’s happening:

I am declaring a read-only variable FCC using const.
My cases are correct.
I am still receiving an error from the UI even though I am obeying the rules.

const FCC = “FreeCodeCamp”; // Change this line

let fact = “is cool!”; // Change this line

fact = “is awesome!”;

console.log(FCC, fact); // Change this line

Your code so far

const FCC = "FreeCodeCamp"; // Change this line
let fact = "is cool!"; // Change this line
fact = "is awesome!";
console.log(FCC, fact); // Change this line

Your browser information:

User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.61 Safari/537.36

Challenge: Declare a Read-Only Variable with the const Keyword

Link to the challenge:

OMG it’s because I changed freeCodeCamp to FreeCodeCamp which has nothing to do with the code but still throws up an error, which is incorrectly described by the UI.
Bug.

It is not a bug. Changing parts of the code that you were not told to change can break code. You should only make the requested changes in these challenges. Doing otherwise means that you have written a bug.

The UI incorrectly described the problem = bug.

You changed things that you should not = bug

So you’re saying that the Help statements don’t have to be accurate? How are they helpful then?

I’m saying that you wrote a bug in your code. I’m digging into the test to see how we test this, but I’m not sure if there is as clear way to catch this user bug.

As a learner, I would expect to make mistakes… but I would not expect your UI, created by experts, to contain errors. It wouldn’t matter so much except that the user is prevented from progressing. I’m having a similar issue with the next challenge in fact… where the Help statement is giving me an instruction which I’ve already fulfilled, but I am not allowed to progress.

It is literally impossible for us to come up with every possible bug you could write. We might be able to make an easy tweak to the tests to catch this one, but in general you can’t expect every challenge to catch every possible way for users to make mistakes.

@JeremyLT Since the tests are looking for very specific values (like in this case), then we could adjust the instructions to state something like. “Make sure to not change the values of the variables.” It is not bullet proof, but might help.

That’s what’s coming to mind for me. We could also split the relevant test into two parts, but it’s already a high number of tests for a simple task.

The Help message said: FCC should be a constant variable declared with const
I was already doing that.
But because I changed freeCodeCamp to FreeCodeCamp (because I took the capitalisation rule too literally) the code wouldn’t pass.

We could add an extra test that appears above the current 2nd one that looks like:

The values of the variables should not be changed.

The test could be:

assert.match(code, /freeCodeCamp/);
assert.match(code, /is cool\!/);
assert.match(code, /is awesome\!/);

I started an issue with two suggestions since occasionally we have a user that misreads the instructions on this challenge. An update to the instructions and a new test are my two suggestions for possible clarifications. It still feels like a lot of tests for 4 small edits, but I don’t see a different way to be super specific about this particular misunderstanding.

When I was working on the tests for the first two projects of the new RWD curriculum, I had to write 5-6 tests for a very simple task and get the order of the tests correct, so that the most applicable hint would show first. When we write challenges that are very specific, our tests need to be more specific to guide the users to the solution. I can definitely see how a user might accidentally make changes to the values in this particular challenge.

I suppose my point is that I’m on the fence about if we want to check if those values weren’t changed. Blindly capitalizing would be a sign of misunderstanding, so I suppose that we do need these checks.

While it does seem silly sometimes to have so many tests to catch all the “what ifs”, I learned to think of it as hopefully preventing time wasted by a user, mod or a helping forum user. If we get a couple of instances per week/month where users create a forum post about such a problem, think about all the other users who do not even take the time to post a question and get so frustrated with a problem that they just give up and leave.

I would say any challenge in the Basic JavaScript section or step in the project-based Basic JavaScript curriculum (coming soon), should always lean on more tests to provide the necessary guidance. The earlier in this curriculum section, the more tests should be written to catch possible user mistakes. Obviously, as the challenges repeat certain concepts through a section, there hopefully will not be a need for as many of these types of tests.

In my mind, it’s less a question of if specific guidance is helpful but rather which things are worth checking for.

We can not think of all the possible “what ifs”, but as they appear as questions or concerns on the forum, we have the opportunity to capture a few more of them. If we get more than one user posting about the same problem of a challenge, I would say it would be worth fixing the challenge to help the many silent others who still struggle with the challenge but are less vocal about it.

Hi Randell, thanks for listening. This challenge is near the beginning of the sequence and could easily put people off from continuing, which is why I’d say it’s worth trying to make it crystal clear.
Maybe, rather than waiting for written feedback from novice users, you could monitor how many people give up at this point to determine how worthwhile it might be to make changes?
Thanks again, Ursula.