Intermediate Cypress test (Intermediate)

Sample questions

5 sample questions from the Intermediate Cypress test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. Which of the following statements accurately describes how Cypress component testing operates?

   1. Cypress component testing cannot be used with frameworks like React or Vue.
   2. Cypress component testing runs in a real browser but does not require a full app page to be loaded.
   3. Cypress component testing requires a full app page to be loaded for accurate rendering.
   4. Cypress component testing is identical to end-to-end testing in functionality.

   Answer: B. Cypress component testing runs in a real browser but does not require a full app page to be loaded.

   Cypress component testing allows developers to test individual components in a real browser environment, which provides a more accurate rendering context compared to unit testing. However, it does not require the full application page to be loaded, unlike end-to-end testing. This makes component testing faster and more focused on the specific component under test.

2. What is a common best practice when creating a custom command for API calls in Cypress?

   1. Avoid using a timeout in the custom command to speed up tests.
   2. Use a custom command that relies on cy.intercept for all API requests.
   3. Use a custom command that wraps cy.request and includes a default timeout of 10 seconds.
   4. Use cy.visit to make API calls and handle responses with cy.get.

   Answer: C. Use a custom command that wraps cy.request and includes a default timeout of 10 seconds.

   A common mistake when creating a custom command for API calls is not setting an appropriate timeout. Using a default timeout of 10 seconds ensures that the command is more robust and avoids flaky tests due to slow network responses. Other options, like using cy.visit or not handling errors, are not suitable for API calls and do not align with best practices.

3. You are trying to stub a GET request to '/api/users' using cy.intercept, but the intercept is not working. What is the most likely reason for this issue?

   1. The response object was not correctly formatted in the intercept.
   2. The URL pattern in the intercept did not match the request URL.
   3. The alias was not used correctly in the wait command.
   4. The intercept was defined after the request was made, so it was not applied.

   Answer: D. The intercept was defined after the request was made, so it was not applied.

   In Cypress, intercepts must be defined before the request is made. If the intercept is defined after the request, it will not be applied, and the request will not be stubbed or spied on as intended. This is a common mistake when using cy.intercept.

4. Which approach is better for waiting for a specific network request and asserting on its response when using cy.intercept, and why?

   1. Using cy.fixture('data.json') to load static data, because it is more efficient for stubbing network requests.
   2. Using cy.intercept with .as('alias') and cy.wait('@alias') to wait for and assert on the response, because it allows precise control over the request and response, and ensures the test waits for the specific network call to complete.
   3. Using cy.wait(3000) to wait for the request to complete, because it is simpler and faster to implement.
   4. Using cy.intercept with a handler function but not aliasing it, because it is unnecessary to wait for the request explicitly.

   Answer: B. Using cy.intercept with .as('alias') and cy.wait('@alias') to wait for and assert on the response, because it allows precise control over the request and response, and ensures the test waits for the specific network call to complete.

   Using cy.intercept with .as('alias') and cy.wait('@alias') is the correct approach because it allows the test to wait for a specific network call and assert on its response. This is more precise and reliable than using cy.wait(3000) or other alternatives, which are less accurate and can lead to flaky tests.

5. When deciding between using cy.intercept and cy.request for handling DELETE requests, what is the correct approach?

   1. Use cy.intercept for stubbing DELETE requests and for making actual DELETE requests to the server because it is more flexible and powerful than cy.request.
   2. Use cy.intercept for making actual DELETE requests to the server because it allows precise control over the request and response, while using cy.request for stubbing DELETE requests.
   3. Use cy.request for stubbing DELETE requests and for making actual DELETE requests to the server because it is more flexible and powerful than cy.intercept.
   4. Use cy.intercept for stubbing DELETE requests because it allows precise control over the request and response, while using cy.request for making actual DELETE requests to the server.

   Answer: D. Use cy.intercept for stubbing DELETE requests because it allows precise control over the request and response, while using cy.request for making actual DELETE requests to the server.

   cy.intercept is used to stub network requests, including DELETE requests, by defining a handler that returns a static response. This allows you to simulate the behavior of a DELETE request without actually hitting the server. On the other hand, cy.request is used to make actual HTTP requests to the server, which is useful for testing real API behavior. When you need to test the application's behavior in response to a DELETE request without affecting the server, cy.intercept is the appropriate choice. However, if you need to test the actual DELETE request and its impact on the server, cy.request is the right tool.