All use cases met but FCC tests are still failing. Why?

[ThomasDirkse]

I am building the FCC Front-end Libraries project ‘25 + 5 clock’.

To the best of my knowledge, all the tests that I have performed seem to indicate that the project is meeting all the use cases. However, when I run the FCC test the test score is ‘16/29 Passed’.
When I look at the test result in more detail there appears to be a consistent pattern. The tests return a value of ‘Some String\n’ where ‘Some String’ is either ‘Break Length’ or ‘Session Length’ and n is the numerical return value of the tests. This is then compared to the expected test result. In all cases the tests would pass when comparing the numerical values except for the tests returning a string concatenation with a numerical value. I cannot see how my project can produce an output as is suggested which leads me to suspect that something has gone awry with the tests themselves.

I hope there is someone who can make some suggestions as to how I can proceed from here.

Many thanks. Thomas.

The general pattern of the error messages for the failing tests is:

 expected **'"some string"\n'** to equal **'expected test value'**

The error messages are as follows:

#Content

5. A value of 5 is not displayed by default: expected ‘Break Length\n5’ to equal ‘5’

6. A value of 25 is not displayed by default: expected ‘Session Length\n25’ to equal ‘25’

#Timer

1. Default values for break length were not properly reset: expected ‘Break Length\n5’ to equal ‘5’

2. expected ‘Break Length\n1’ to equal ‘1’

3. expected ‘Break Length\n9’ to equal ‘9’

4. expected ‘Session Length\n21’ to equal ‘21’

5. expected ‘Session Length\n29’ to equal ‘29’

6. Value in element with id of “break-length” is less than 1.: expected ‘Break Length\n1’ to equal ‘1’

7. Value in element with id of “break-length” is greater than 60.: expected ‘Break Length\n60’ to equal ‘60’

8. expected ‘25’ to equal ‘Session Length\n25’

9. Break time didn’t start with the correct value.: expected 4 to be at most NaN

10. Timer has switched to Break time, but it didn’t start with the correct value.: expected 4 to equal NaN

11. Timer has switched back to Session time, but it didn’t start with the correct value.: expected 0 to equal NaN

My code can be viewed in the following CodePen: https://codepen.io/ThomasDirkse/pen/MWrOBXe?editors=0100

FCC Challenge:
https://www.freecodecamp.org/learn/front-end-development-libraries/front-end-development-libraries-projects/build-a-25–5-clock

[colinthornton]

Would you mind linking to the challenge page as well?

Without looking at your code, it would appear that the automated tests are grabbing the text of a certain element, and expecting to see “5”, but seeing “Break Time\n5” instead. Which to me would indicate that you’ve misplaced an id that should be on the number element to one of its ancestors.

[ThomasDirkse]

Link to challenge added to the original post. Thanks, Colin, for looking into this. I will in the meantime look for any possible id issues.

The code that could relate to one of the errors would be in lines 23 - 28.

[colinthornton]

Ah, I was on the money.

You’ve got a container element with the id break-length inside of which is another element with the same id

<div id="break-length">
  <BreakLength
   breakLength={this.state.breakLength}
   handleIncrements1={this.handleIncrements} />
</div>

// inside the BreakLength component
<div id="break-length">{this.props.breakLength}</div>

Remember, ids are exclusive, they should only be used once on the page.

Basically the automated tests are querying the document for an element with the break-length id, and they’re finding the whole container element which includes the label.

[ThomasDirkse]

@colinthornton

id="break-length"

Colin, you’re a star! Fantastic. You were absolutely right. Many, many thanks. I have been bashing my head against this for two days now. Also somewhat embarrassed about such an elementary mistake but I don’t think I will forget this lesson anytime soon.

Also thank you for helping me out so quickly as well. Very much appreciated.

Many thanks, Thomas.