Chapter 4: Resiliency Ticket: Handling Errors - No validation code


Unit test error-handling pass, but validation code does not appear.
What could be the problem?
Thanks for the help.

I haven’t had any difficulties with this one, whatsoever.
I think you might be facing a different issue (implementation wise).

Please, be sure to read the question throughout and fully understand the implementation details required by this ticket, before proceeding to the code:

A try/catch block is already included for you in  getMovieByID(). Use the variable e to figure out if the InvalidId error is being thrown, and then return null in this case.

And pay attention to all the details, i.e:

When the error e is caught, it has type Error. You might want to convert this to a string.

And from the moviesDAO.js file itself

// TODO Ticket: Error Handling
// Catch the InvalidId error by string matching, and then handle it.

Hope that it helps.

Update :
One more hint for you (that I think may help you, find the cause of an issue you’re facing):
You might want to inspect the terminal, once you run the tests, as there are actually 2 test suites being run - error-handling.test.js and writes-with-error-handling.spec.js :slight_smile:

I do it this way:

expect(e).not.toBeUndefined()
expect(e.toString()).toContain(“Error: Argument passed in must be a single String of 12 bytes or a string of 24 hex characters”)
return null

Did I miss something?

Ticket X fails but I’m sure my implementation is correct! was posted here for a reason, several really but the primary one:

Do Not Edit Unit Tests

The question was not asking you to “Edit the unit test to match the thrown error message” just as you have actually done. What you were asked was to edit the getMovieByID() function in the catch block.

Also, read the existing thread Ticket, Handling Errors because it basically serves as instruction for what you are supposed to do.

The real lesson here is to always read the existing threads here before you post. Especially the one that was deliberatly pinned to the top of the list for everyone to read.

Hi!
Thanks for the reply. I read all the related thread before I made this. I never change unit tests as always told to us. The code I put in spoiler before was in my catch block. Is it wrong?
I read the pinned thread again.
Maybe I made a mistake earlier?
What do you think?
Is it possible to all the untuched unit tests are passed and nonetheless I made a mistake and that is the reason why this happened?

I’m thinking the blurred out image ( spolier ) you posted earlier shows the unit test that has been changed. This is not the code in getMovieByID(). If you changed unit tests you really should restore them to the original state from the archive.

I’ll state it again that the question is basically answered in the other threads, when you actually go and read the content.

I don’t want to post my code, but it seems you don’t belive me.

This is my whole getMovieByID:

static async getMovieByID(id) {
try {
/**
Ticket: Get Comments

  Given a movie ID, build an Aggregation Pipeline to retrieve the comments
  matching that movie's ID.

  The $match stage is already completed. You will need to add a $lookup
  stage that searches the `comments` collection for the correct comments.
  */

  // TODO Ticket: Get Comments
  // Implement the required pipeline.
  const pipeline = [
    {
      $match: {
        _id: ObjectId(id)
      }
    },
	 {
$lookup: {
  'from': 'comments', 
  'let': {
    'id': '$_id'
  }, 
  'pipeline': [
    {
      '$match': {
        '$expr': {
          '$eq': [
            '$movie_id', '$$id'
          ]
        }
      }
    }, {
      "$sort": {
        "date": -1
      }
    }
  ], 
  'as': 'comments'
}

}
]
return await movies.aggregate(pipeline).next()
} catch (e) {
/**
Ticket: Error Handling

  Handle the error that occurs when an invalid ID is passed to this method.
  When this specific error is thrown, the method should return `null`.
  */

  // TODO Ticket: Error Handling
  // Catch the InvalidId error by string matching, and then handle it.
  console.error(`Something went wrong in getMovieByID: ${e.toString()}`)
  expect(e).not.toBeUndefined()
  expect(e.toString()).toContain("Error: Argument passed in must be a single String of 12 bytes or a string of 24 hex characters")
 // throw e
  return null
}

}

And this is my error-handling.test.js:

import MoviesDAO from “…/src/dao/moviesDAO”

const badObjectId = “helloworld”

describe(“Get Comments”, async () => {
beforeAll(async () => {
await MoviesDAO.injectDB(global.mflixClient)
})

test(“Handles invalid ID error correctly”, async () => {
const response = await MoviesDAO.getMovieByID(badObjectId)
expect(response).toBeNull()
})
})

What you don’t appear to understand here is that those expect() calls have no place here. Those are for “unit testing” and this is not how you implement the code.

Bottom line is that you are not supposed to be returning null where there is any other error than the specified type raised in the function.

That is what is being tested in the integration test, and that is why your code fails.

2 Likes

Thanks a lot, that was helpful, I combinated too much.
I don’t know why I complicate, this is a simple if else case.