Test shows "yes", status page says "no"

Hello,
Running

npm test -t create-update-comments

displays that all the tests passed. But the status page displays

Create/Update Comments: Unable to update comment

Where is the status page logic to cross reference what it thinks is correct?
Thank you

I found a discrepancy by looking at the server interactions and adding some console.error() calls.
Onward…

Hi Bill,

I just completed this chapter and did not find any discrepancy. Were you able to get the status page to produce the correct validation code?

Could you share the discrepancy so that we can improve this?

Hi Nathan,

I went through so many variations of things that I now forget the exact delta.
It may have been with the object ID argument, I’m sorry. There was one oddity
encountered in how the test harness runs that I just reconfirmed.

When doing the “User Management” ticket, in the usersDAO.js function

static async addUser(userInfo) 

I first tried the line

await users.insertOne( userInfo, ...

figuring all the information is in the argument so why not? I observed that an ID value was written into the argument object itself. The user management test displayed

Expected value to equal:
  {"_id": "5c4261db18be70341c9d78c0", "email": "magicz@cats.com", "name": "Magical Mr. Mistoffelees", "password": "somehashedpw"}
Received:
  {"email": "magicz@cats.com", "name": "Magical Mr. Mistoffelees", "password": "somehashedpw"}

The expected value seems to be (it truly is) the exact same object as that which was passed into insertOne().
My explanation is that user-management-test.js imports

UsersDAO from "../src/dao/usersDAO"

It does a direct call (vs. a REST call for example) to

const actual = await UsersDAO.addUser(testUser)

It then gets the newly created user via

const user = await UsersDAO.getUser(testUser.email)

It then performs the check via these lines

// for comparison, we delete the _id key returned from Mongo
delete user._id
// Bill's output line -> console.log('testUser', testUser, '\nuser', user);
expect(user).toEqual(testUser)

With testUser having its _id field set via addUser() above the comparison fails.
I ended up using

await users.insertOne( {name: userInfo.name, email: userInfo.email, password: userInfo.password},

and the test ran successfully. So maybe do this line too prior to the expect.x.equal.y line?

delete testUser._id
  • Bill

I first tried the line await users.insertOne( userInfo, ... figuring all the information is in the argument so why not?

@Bill_89515, I took my working example and changed it to use await users.insertOne( userInfo, ... as you did and the test failed. We could spend the time to find out why not, but it almost certainly is some kind of type conversion error, and life is so, so short.

I suggest that you actually expand the object.

It happened the same to me, and I found out why.

If I put this in the updateComment method:
const updateResponse = await comments.updateOne(
{ _id: commentId, email: userEmail },
{ $set: { text, date } },
)

The test passes, but it doesn’t work in the status page. If I put the commentId like this ObjectId(commentId) it works in the status page as well.

Hope it helped.

Thanks, worked for me.

Thank you. A variation of this fixed my really mystifying problem. I had the unit tests failing and the front-end fine with it :slight_smile:

1 Like

Sorry you all had issues with this. The newest versions of the handouts should correctly cast in all instances. Please report if they don’t!

i am still having issues with this. there is no combination with ObjectId of using it or not using it that will make the frontend pass

I will say for addComment the ObjectId is manditory for the unit test to pass. moving on this is broken

i had this exact issue too and delted the delete user._id well commented it out because i thought that was the prudent thing to do. Although in a cascade effect now everything else i am working on is broken. So

Please do not edit the test files or the API layers. Doing so will (almost assuredly) break multiple things.

It’s very hard for us to differentiate signal from a bug on our end vs a bug in implementation. However, if the unmodified unit tests are passing and the status page is not validating, then this is our bug. Please direct message me with your implementation along with your uri and I will grant credit if I can’t spot anything wrong.

@nathan.leniz I don’t know how to do a direct message but the issue is stemming from this initial post

Bill_89515

When doing the “User Management” ticket, in the usersDAO.js function

static async addUser(userInfo) 

I first tried the line

await users.insertOne( userInfo, ...

figuring all the information is in the argument so why not? I observed that an ID value was written into the argument object itself. The user management test displayed

Expected value to equal:
  {"_id": "5c4261db18be70341c9d78c0", "email": "magicz@cats.com", "name": "Magical Mr. Mistoffelees", "password": "somehashedpw"}
Received:
  {"email": "magicz@cats.com", "name": "Magical Mr. Mistoffelees", "password": "someh

In that unit test we insert this document, then look it up and delete the _id off of it since that isn’t dereministic.

These lines, 34 - 38

    // we should be able to get the user
    const user = await UsersDAO.getUser(testUser.email)
    // for comparison, we delete the _id key returned from Mongo
    delete user._id
    expect(user).toEqual(testUser)

In the afterAll lifecycle method we do this operation.

  afterAll(async () => {
    await UsersDAO.deleteUser(testUser.email)
  })

If you go in with Compass or through the mongo shell and look for this user, how many documents are returned? If 1 or more, delete it with prejudice. There should have been a unique index on email when you restored.

In the validation page, completely random users are created (and destroyed) during the integration tests. Among the things that are checked is can this user be created, does the api correctly return an error if the same email is used for another user account, and can it be deleted (provided method).

I apologize, the title for this thread is create/update comments so a bit confusing to jump into the user management stuff here.

hi Nathan… I am looking it up and nothing is returning for my

query

db.users.findOne({_id: ObjectId("5c759509d2e4182824d561b8")})
dbKoda Mongo Shell>db.users.findOne({_id: ObjectId("5c759509d2e4182824d561b8")})
null
### execution ended

Make sure you’re using the mflix database, and search by the name or email address. It may very well be deleting the proper document but there are others that were erroneously inserted.

I’ve made a note of this and for future runs we’ll be running a delete all on the email.

im confused how that is not passing the test… i am searching by id name and email nothing comes up…

here is output

  expect(received).toEqual(expected)

    Expected value to equal:
      {"_id": "5c759509d2e4182824d561b8", "email": "magicz@cats.com", "name": "Magical Mr. Mistoffelees", "password": "somehashedpw"}
    Received:
      {"email": "magicz@cats.com", "name": "Magical Mr. Mistoffelees", "password": "somehashedpw"}

    Difference:

    - Expected
    + Received

      Object {
    -   "_id": "5c759509d2e4182824d561b8",
        "email": "magicz@cats.com",
        "name": "Magical Mr. Mistoffelees",
        "password": "somehashedpw",
      }

      36 |     // for comparison, we delete the _id key returned from Mongo
      37 |     delete user._id
    > 38 |     expect(user).toEqual(testUser)