Next page button component tests - Clean branch

[jarmoza]

(cherry picked from commit 443f742) Remaking this PR off a clean branch from dev.

This PR closes #412.

As mentioned in the issue, the following tests have now been implemented for the next-page component:

• Does the label on next page button correspond to the current page (This is tested across home, categorization, and annotation pages – where a 'next page' button exists.)
• Does next page disabled status correspond to page accessibility
• When clicked is setCurrentPage mutation fired once with the correct parameters

[surchs]

Sorry, don't have the time. Asking @rmanaem to take over!

[rmanaem]

Everything looks good! One thing that @surchs wanted to know and I'd like to mention is why did you use the store getters and mutations instead of mocking them in the test?

[surchs]

Thanks @rmanaem for taking over. Like I said in the call, my question is whether we need to mock the getters by copying the actual logic into the test. I think one alternative is to just write the output that should get fed to the component as a literal, making the test clearer to understand. The other would be to reuse the getters in the store and then do more of an integration test.

I prefer the former, the latter also works. But the problem I see with copying the whole logic here is that from reading the test I don't get a clear idea of what data goes into the component (missing out on clarity), and I also don't know if I'm in sync with the store (because the copy might have fallen out of sync).

[jarmoza]

Understood @surchs and @rmanaem. The confusion here is that the next page component is a little bit different in that testing it could act like an integration test since its actual functionality is linked to the app state.

However, this should be tested in our 'e2e' page tests and full e2e test.

I'm revising the setup and tests now to be a proper component test for the next-page button (the former scenario in @surchs comment above).

[jarmoza]

Given the above comments from @surchs and @rmanaem, I opted to convert the tests away from integration-style and more to be component specific. This PR now includes tests for the next-page component for the following scenarios:

*Does instruction text appear above the next page button when the button is disabled
*Button is enabled when next page is accessible and vice-versa
*Button is disabled when next page is not accessible
*Does the label on the next page button correspond to the text for the current page?
*When enabled, next page button moves to next page's url and sets current page in the store

In addition, a small bug was noticed and this has been fixed in a separate commit. Instructions text that was to appear above the next-page button now appears when the next page the button leads to is inaccessible. Previously it was checking the current page's accessibility. The idea behind the instructions text, however, is to give users instructions as to how to enable the next page button and to proceed.

[jarmoza]

Just to note that this is currently failing the last component test on github only and not Cypress locally.

1) next page button
       When enabled, next page button moves to next page's url and sets current page:
     TypeError: Cannot set property message of  which has only a getter
      at modifyErrMsg (http://localhost:8080/__cypress/runner/cypress_runner.js:154708:15)
      at $Cy.retry (http://localhost:8080/__cypress/runner/cypress_runner.js:146130:29)
      at onFailFn (http://localhost:8080/__cypress/runner/cypress_runner.js:131085:21)
      at tryCatcher (http://localhost:8080/__cypress/runner/cypress_runner.js:8914:23)
      at Promise._settlePromiseFromHandler (http://localhost:8080/__cypress/runner/cypress_runner.js:6849:31)
      at Promise._settlePromise (http://localhost:8080/__cypress/runner/cypress_runner.js:6906:18)
      at Promise._settlePromise0 (http://localhost:8080/__cypress/runner/cypress_runner.js:6951:10)
      at Promise._settlePromises (http://localhost:8080/__cypress/runner/cypress_runner.js:7027:18)
      at _drainQueueStep (http://localhost:8080/__cypress/runner/cypress_runner.js:3621:12)
      at _drainQueue (http://localhost:8080/__cypress/runner/cypress_runner.js:3614:9)
      at ../../node_modules/bluebird/js/release/async.js.Async._drainQueues (http://localhost:8080/__cypress/runner/cypress_runner.js:3630:5)
      at Async.drainQueues (http://localhost:8080/__cypress/runner/cypress_runner.js:3500:14)

Currently investigating the cause.

[rmanaem]

@jarmoza The last test Is breaking locally on my end too.

[jarmoza]

@rmanaem Here's a mystery.

[jarmoza]

@rmanaem What version of Cypress are you running locally?

[rmanaem]

@jarmoza v12.9.0

[jarmoza]

With the update to Cypress 12, new cross-origin security measures prevent full component testing of navigation to a new page, particularly they block the click event from being tested.

In this case, the click event fornext-page is the mutation setCurrentPage. The final test has been amended to just check that the new requested url includes the next page's name.

[surchs]

This seems to be quite interesting @jarmoza. Could you explain briefly what you have found or how Cypress is now preventing you from testing the button press when it passed earlier? I am assuming you are referring to the new addition of cross-origin testing: https://docs.cypress.io/guides/guides/cross-origin-testing ?

edit: the reason I'm asking is that the cypress error message refers to a getter being written to, so it would be important to know that this is in fact somehow linked to cross-origin requests.

[jarmoza]

Okay @rmanaem. Requested changes + some more cleanup committed.

[jarmoza]

This seems to be quite interesting @jarmoza. Could you explain briefly what you have found or how Cypress is now preventing you from testing the button press when it passed earlier? I am assuming you are referring to the new addition of cross-origin testing: https://docs.cypress.io/guides/guides/cross-origin-testing ?

edit: the reason I'm asking is that the cypress error message refers to a getter being written to, so it would be important to know that this is in fact somehow linked to cross-origin requests.

@surchs Yes, and this is a good reminder to write down/screen capture key error messages as we come across them. Thankfully we have one above.

I'll try to summarize what Arman and I were seeing when attempting to test the request url and click event. The general consensus we reached was that once a click on the button was made the request to change url could be intercepted, but the click event itself was never fired. Depending on the order of the calls of intercept and spying on the store commit function, we received the following behaviors.

1. The error Cannot set property message of '' which has only a getter - when the traceback of the object this is emanating from is expanded, we find this actually refers to an error message object and nothing in our app/store code.
2. Click followed by a page load timeout after 60 seconds
3. The error Blocked a frame with origin "http://localhost:8080" from accessing a cross-origin frame...

The reason above why I was not initially seeing these errors was because I was using Cypress 10.3 locally. Once upgraded to 12.9, these errors above came up. You would think that moving from 'localhost:8080/' to 'localhost:8080/mynextpage' would have nothing to do with cross-origin handling since the origin should remain 'localhost', but as per error 3 and some stackoverflow reading about an error similar to 1 resolved by disabling a Cypress Chrome web security config field, it does seem to have something to do with a Cypress change between 10.3 and 12.9.

As an addendum:

The initial error on 10.3 I was experiencing was when the click tests were separated across two individual tests. Once a 'navigation' had been triggered via click, the Cypress testing environment would automatically fail the next test with an error reading something like Failure to attachTo CSS or HTMLElement. So the test would not even begin. (Our initial guess was that page navigation is not something compatible with component tests, but some online reading appears to show otherwise.)