Issue tracker tests failing even though output matches sample

[lkodanko]

Tell us what’s happening:
All but one put and delete requests are failing. However, I’m looking at the res.send results and they match the sample project perfectly. I’m at a loss.

Your project link(s)

solution: https://boilerplate-project-issuetracker-1.lukekodanko.repl.co
https://replit.com/@LukeKodanko/boilerplate-project-issuetracker-1#routes/api.js

Your browser information:

User Agent is: Mozilla/5.0 (X11; CrOS x86_64 13729.45.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36.

Challenge: Issue Tracker

Link to the challenge:

freeCodeCamp.org

[Sky020]

Hello there,

Top tip: You can use the browser console to see the full assertion error:

The timed-out tests suggest your app is crashing. I can now see there are cors errors.

Hope this helps

[lkodanko]

Sky020, that console tip actually helped me a lot in a previous challenge. However, in this challenge it is unclear to me what the problem is. The first error I see is that NaN expected to be above NaN. However, as the results appear to be identical to the example project I don’t know where to look for that. And I don’t see anything else in that message that clarifies.

[Sky020]

I do not see the NaN expected to be above NaN. What i do see, is as in the above picture:

expected { Object (error, _id) } to deeply equal { Object (result, _id) }

Meaning one of your conditions is for error handling is firing when it should not be. The other errors that read expected x to deeply equal x suggests your response has typos.

Here is a link to the tests, if you want to go through them, and try to replicate the output:

• https://github.com/freeCodeCamp/freeCodeCamp/blob/main/curriculum/challenges/english/06-quality-assurance/quality-assurance-projects/issue-tracker.md

[lkodanko]

Perfect. I can go through the tests one by one and see what is failing. Thanks!

[lkodanko]

For anyone else that might experience the same issue. The GET test passed even though I failed to include _ID as one of the fields. However, the PUT test then assumed a proper GET (including _ID) as a way to test that PUT worked properly. So once I fixed my GET my PUT passed the test.

[mientje]

This is really a great tip.

[shekine]

Lifesaver! I stared at my PUT request for many hours today alone comparing every little thing - even found the example site had an error that shouldn’t have passed. My GET was passing, but I reexamined it after seeing your comment and that fixed my PUT request.

I had to fix the way my find() filtered _id and open. Switched to ObjectId and specified whether open was a boolean or a string. Hope this helps someone else!