The State Hook lessons - Oops! The test returned an error.. keeps showing up at every exercise

Hey there!
Today for the whole day I had this dumb error showing up for every single exercise of the The State Hook lessons:

"Oops! The test returned an error. Maybe you have a syntax error, or a typo. Hide error."
/home/ccuser/node_modules/chai/lib/chai/assertion.js:141
      throw new AssertionError(msg, {
      ^
AssertionError: Try checking your code again. You likely have a syntax error.: expected true to equal false
    at Suite.<anonymous> (/home/ccuser/workspace/the-state-hook-lesson-review/test/test.js:13:10)
    at describe (/home/ccuser/node_modules/e[4mmochae[24m/lib/interfaces/bdd.js:47:10)
    at Object.<anonymous> (/home/ccuser/workspace/the-state-hook-lesson-review/test/test.js:5:1)
e[90m    at Module._compile (internal/modules/cjs/loader.js:1015:30)e[39m
    at Module._compile (/home/ccuser/node_modules/e[4mpiratese[24m/lib/index.js:99:24)
e[90m    at Module._extensions..js (internal/modules/cjs/loader.js:1035:10)e[39m
    at Object.newLoader [as .js] (/home/ccuser/node_modules/e[4mpiratese[24m/lib/index.js:104:7)
e[90m    at Module.load (internal/modules/cjs/loader.js:879:32)e[39m
e[90m    at Function.Module._load (internal/modules/cjs/loader.js:724:14)e[39m
e[90m    at Module.require (internal/modules/cjs/loader.js:903:19)e[39m
e[90m    at require (internal/modules/cjs/helpers.js:74:18)e[39m
    at /home/ccuser/node_modules/e[4mmochae[24m/lib/mocha.js:220:27
    at Array.forEach (<anonymous>)
    at Mocha.loadFiles (/home/ccuser/node_modules/e[4mmochae[24m/lib/mocha.js:217:14)
    at Mocha.run (/home/ccuser/node_modules/e[4mmochae[24m/lib/mocha.js:469:10)
    at Object.<anonymous> (/home/ccuser/node_modules/e[4mmochae[24m/bin/_mocha:404:18)
e[90m    at Module._compile (internal/modules/cjs/loader.js:1015:30)e[39m
e[90m    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1035:10)e[39m
e[90m    at Module.load (internal/modules/cjs/loader.js:879:32)e[39m
e[90m    at Function.Module._load (internal/modules/cjs/loader.js:724:14)e[39m
e[90m    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)e[39m
e[90m    at internal/main/run_main_module.js:17:47e[39m {
  showDiff: e[33mtruee[39m,
  actual: e[33mtruee[39m,
  expected: e[33mfalsee[39m
}

At one point I got so frustrated that I thought the comments I use to make in the code were the problem. They were not.
The only thing that worked has been substituting my code with the code solution, this has solved the problem every time. Once the error disappeared, if I replaced the code solution with my previous code the editor would not throw the error anymore and everything just would work as supposed.

Also none of the js files indicated in the error are the ones directly related to the exercises.

I’d like to understand more about this if anyone has any clue :slight_smile:

Hi @usernamegiapreso
I know this frustration and often end up doing things as you described.

The only file in the error message you can find in the directory that stores all the related work files is this:

/home/ccuser/workspace/the-state-hook-lesson-review/test/test.js

This test file runs through the js file on “run” and if this file directly throws the error, it’s rather easy to solve. But unfortunately, this file imports the other test modules which can’t be accessed and no one knows what they check, I guess…

1 Like

I find comfort in knowing I am not alone

1 Like

We’d have to see the code your wrote to be able to understand what is was complaining about. However - sometimes I have the same issue with the testing suite throwing false errors. Sometimes refreshing helps, something not. Sometimes if I compare their code to mine can’t see any difference yet still get a problem. I haven’t noted in which lessons I had this problem so might have been the same as yours.

1 Like

I’m finishing up the Effect Hook lessons now and I didn’t encounter this error one single time.
However I’ve been too dramatic, I didn’t really had it in every single lesson of the State Hook, but the majority of them. My code worked however, I can share it no prob, but is not just one exercise as I was saying.
What I was truly curious about this error is this line:
expected true to equal false
and the last three:

  showDiff: e[33mtruee[39m,
  actual: e[33mtruee[39m,
  expected: e[33mfalsee[39m

Ok, forget about the only accessible file in the mess of cryptic error messages and file paths. Sometimes they do not seem to be related to the exercise in the least. Little premature I guess ¯_(ツ)_/¯

The next lesson: The Effect Hook Lesson is also one of those examples where the test file in the folder doesn’t seem to be related to the exercise at all and the reasons why the code fails is unclear to me:

The problem in step 1 was not wrapping the single parameter in the arrow function inside of setTime() in parenthesis. (Or did I miss that they are not optional in React?)


No idea what the problem was here, so I replaced it with the solution. This failed:

import React, { useState, useEffect } from 'react';

export default function Timer() {
  const [time, setTime] = useState(0);
  const [name, setName] = useState('');

  useEffect( () => {
    const intervalId = setInterval( () => {
      setTime((prevTime) => prevTime + 1)
    }, 1000);
    return () => {
      clearInterval(intervalId);
    }
  }, []);
  const handleChange = ({ target }) => setName(target.value);
  
  return (
    <>
      <h1>Time: {time}</h1>
      <input 
        value={name} 
        onChange={handleChange} 
        type='text'
      />
    </>
  );
}

So in case, you haven’t done this exercise yet: Don’t forget the parenthesis!

1 Like

Hahaha @mirja_t amazing, thanks for the advice, I’m at stateless components atm, in this exercise you’ve linked I had to eventually accept my fate too and use the code solution to move forward.
What I realised in my case was that this didn’t pass:

  useEffect(
    ()=>{
      /*Effect*/
      /*return Cleanup*/
    },[/*Dependency Array if any*/]
  );

While this passed:

  useEffect(()=>{
      /*Effect*/
      /*return Cleanup*/
    },[/*Dependency Array if any*/]
  );

It’s an insignificant difference and you could tell that my approach of “newlining” the incoming parameters of useEffect() it’s different from what is usually seen, but it should be the same so I don’t feel in error and for me this way it’s easier to see if I’m closing the parentheses correctly.

The test.js unfortunately is not that helpful in these cases.

I figured out however that:

  showDiff: e[33mtruee[39m,
  actual: e[33mtruee[39m,
  expected: e[33mfalsee[39m

is the result of comparing the actual solution (provided by the user) with the expected solution (the suggested code solution provided by CodeAcademy). showDiff is true because the file(s) doing this check is finding differences between the two solutions. Differences that could in fact be as small as the one outlined above :slight_smile:

Cheers

1 Like

Ah, ok. Possibly then in my second case the problem might have been that I had a space between the two opening parenthesis where you had a line break…
I also noticed that when I open the solution to compare it to my code, in the window with my code there sometimes is still an old version although I did save it several times.
It can be tedious to find these errors, especially in the first case on step one where the interval wasn’t cleared yet and my notebook became warmer and warmer on my legs due to the overheating accu :sweat_smile:

xD in that exercise at first I didn’t use a wrapper function to wrap the first parameter of setInterval, big mistake… :slight_smile:

1 Like

Yeah, it can be pedantic and just want it the way it wants it even though the code would run perfectly in another environment. Not just for the React content, I’ve found previously it can complain if you have a space different or have written it a slightly different (but acceptable) way.

When it’s being a particular pain I report it as a bug. Select the “get unstuck” option, the “bugs” option, and let them know there’s a problem.

1 Like

I don’t think it’s a bug though, it’s just (sometimes) too stringent with the definition of correct answer