Pomodoro Clock Mysteriously Failing Only One Test!

I’m only one single failing test away from my front end libraries certification!

My Pomodoro Clock only uses React & Font Awesome (I have a bootstrap CDN in there but I didn’t use any bootstrap).
Here’s my Pomodoro Clock + testing suite on Code Pen:

As far as I can tell my clock works perfectly but the testing suite claims that when the timer hits 0, the audio doesn’t play:

    1. When a countdown reaches zero (NOTE: timer MUST reach 00:00), a sound indicating that time is up should play. This should utilize an HTML5 audio tag and have a corresponding id=“beep”.
      Timer has reached zero but audio is not playing while it should.: expected true to be false
  • AssertionError: Timer has reached zero but audio is not playing while it should.: expected true to be false

But in all of my testing, in every scenario where the timer hits 0, the audio plays reliably. No matter what I do I’m unable to produce a scenario where the audio fails to play.

What makes this scenario more difficult is the fact that the testing suite takes over 5 minutes to run, so I can’t simply tweak random little things and then run the testing suite to try to workaround whatever is getting the test bundle’s knickers in a twist.

Making projects that work perfectly is easy but freeCodeCamp’s testing suite is going to haunt my nightmares for the rest of my life.

When I test your timer, the sound does not play until the next break or session starts. When it gets to 00:00 nothing happens and then it shows the full time of the next session or break.

1 Like

Hm I didn’t realize I had it set to only activate when the timer switches between session and break… I thought it would call and play the audio tag the moment the timer hit zero. I’ll try moving the audio function to make sure it’s only contingent on the timer being zero & it doesn’t wait for the switch…

That worked thank you!!!

In normal operation there was no way for the timer to reach 0 without also switching between break & session, and I thought the way I had it set up the tag would play the moment it hit zero.
I just made a useEffect hook to watch for the display time to reach 0 and then play the audio tag.

This project’s requirements have had a bug since it was originally created. If you get it to pass all the tests, your timer will always add an additional second for each minute the session or break runs. Why? Because a real session/break timer would do something like the following if I were to set both the session and break to 1:00:

01:00 session starts
00:59
00:58
.
.
.
00:03
00:02
00:01
00:00 sound plays (session ends/ break starts for 1 min simultaneously)
00:59
00:58
.
.
.
00:03
00:02
00:01
00:00 sound plays (break ends/ session starts for 1 min simultaneously)
.
.
.
and so on

Instead, the project tests force you to create a timer that adds an extra second to each minute the session and break run:

01:00 session starts
00:59
00:58
.
.
.
00:03
00:02
00:01
00:00 sound plays (session ends)
01:00 break starts for 1 min (extra second occurs here)
00:59
00:58
.
.
.
00:03
00:02
00:01
00:00 sound plays (break ends)
01:00 session starts for 1 min (extra second occurs here)
.
.
.
and so on

Basically, when the first session hits `00:00` that is the equivalent of the next break's `01:00` , so having the break start counting again at `01:00` adds a second that should not exist. It is only a second but over an hour, you would add an extra whole minute for both the session and the break times.  Probably not that big of deal in real life for this application, but the fact that it the tests force bug like that has always bothered me.  In my timer shown to the public, I fixed mine to work correctly.
1 Like