TICKET: Paging.tests

MongoDB University M220JS: MongoDB for Javascript Developers
#1

this week is been a difficult one. I can’t get the Paging tests to pass. I can however, pass subsequent aggregation test but not the Paging. what looks like a problem is that if I want to skip a test and go to the next one, then the STATUS integration engine DOES NOT process the test being processed until all the previous TICKETS are closed and therefore no code is provided to close that TICKET until the previous TICKET test passes.

My problem is NOT A JAVASCRIPT issue, but rather the methodology being used to test the student’s knowledge.

ANYWHO: this week is gone!

#2

Sorry to hear that,

The paging is all done with two methods .limit() and .skip().

The .skip() is the only one that’s a little more complicated because you want figure out how many items to skip based on the page number. For example if you are displaying 20 items per page, then the first page would start with item 1-20, page 2 with items 21-40, page 3 with items 41-60 and so on.

To figure this out you have to do some multiplication to figure out how many items to skip.

Not sure if you’re having problems with this or something else. If you’d like to some help getting past this ticket please post where you’re stuck.

#3

thank you for your answer, I know how to do paging of a large database and that’s not the issue. the issue is that the tests don’t pass and debugging environment is very difficult and not intuitive…

Anywho: the time is gone and so is the week.

#4

Hi,
Even i ran test successful but i still can’t pass it.

#5

it looks like I wasn’t the only one having problems with the labs this week. Love the course, not the labs…

will have to stop here and concentrate on other things…

Thanks a bunch, hopefully you’ll fix the issues when I take it on the next go-round…

#6

Thanks to pawlowsg’s tip.
My error message are as follows:
Is it a infra. issue?

Paging
    √ Supports paging by cast (916ms)
    × Supports paging by genre (5026ms)
    √ Supports paging by text (1220ms)

  ● Paging › Supports paging by genre

    Timeout - Async callback was not invoked within the 5000ms timeout specified by jest.setTimeout.

      48 |   })
      49 | 
    > 50 |   test("Supports paging by genre", async () => {
         |   ^
      51 |     const filters = { genre: ["Comedy", "Drama"] }
      52 | 
      53 |     /**

      at Spec (node_modules/jest-jasmine2/build/jasmine/Spec.js:85:20)
      at test (test/paging.test.js:50:3)
      at tryCatch (node_modules/regenerator-runtime/runtime.js:62:40)
      at Generator.invoke [as _invoke] (node_modules/regenerator-runtime/runtime.js:296:22)
      at Generator.prototype.(anonymous function) [as next] (node_modules/regenerator-runtime/runtime.js:114:21)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 2 passed, 3 total
Snapshots:   0 total
Time:        12.125s
Ran all test suites matching /paging/i.
Teardown Mongo Connection
  console.error src/dao/moviesDAO.js:266
    Unable to issue find command, MongoNetworkError: connection destroyed, not possible to instantiate cursor
#7

Hi @ericliu0715

The error output indicates that you should review your paging by genre code as it appears to be failing.
I’d suggest re-reading lines 251-261 which have some suggestions on what should be done to update this to pass the test.

Hope this help!
Eoin

#8

For the case
expect(totalNumMovies).toEqual(31675)
The number of expected data is 31675
Since it replied “timeout”, I suspected that it takes too much time to response matched data.

Therefore, I tried to modify the test case with “Action”
{ genre: ["Comedy", "Drama"] } => const filters = { genre: ["Action"] }
and I have previewed the actual result by performing query via Compass
The actual no. of data which contains genre “Action” is 5917.

Eventually, my custom test case is passed successfully.
I think the tolerance of response time is about performance instead of correctness

#9

Hi @ericliu0715

That’s an interesting hypothesis around the “timeout”, it looks like your Atlas cluster is located locally to you so it should be relatively responsive as it located in the same region. Could there be any local network issues or VPNs that may be adding latency to servicing the query to your cluster ?

I’ll take a note of how we can better match the test to correctness rather than to performance issues in terms of networking as you’ve highlighted.

Kindest regards,
Eoin