Advanced Cypress test (Advanced)

Sample questions

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

1. In a project using Cypress for end-to-end testing, how can you ensure that commands that are retried by default (such as queries and assertions) do not cause tests to hang indefinitely if elements take longer than expected to appear?

   1. Use the 'retries' configuration option to set a timeout for commands that are retried.
   2. Use the 'commandTimeout' configuration option to set a global timeout for commands that are retried by default.
   3. Use the 'defaultCommandTimeout' configuration option to set a global timeout for commands that are retried by default, such as queries and assertions.
   4. Set the timeout for all commands using the 'timeout' parameter in the 'cy' command.

   Answer: C. Use the 'defaultCommandTimeout' configuration option to set a global timeout for commands that are retried by default, such as queries and assertions.

   In Cypress, you can control the timeout for commands that are retried by default (such as queries and assertions) using the 'defaultCommandTimeout' configuration option. This option sets a global timeout for these commands, ensuring that tests do not hang indefinitely if elements take longer than expected to appear. The other options are either incorrect or not directly related to managing test execution timeouts for retried commands.

2. A developer is facing issues with debugging test failures in a CI pipeline due to insufficient logging. Which of the following is the correct approach to set up logging for test execution in a CI pipeline using Cypress?

   1. Use the default Mochawesome reporter and view logs in the generated HTML files.
   2. Use the Cypress built-in logging feature without any additional configuration.
   3. Use the JUnit reporter and configure CI to store and display logs from the XML output.
   4. Install a custom plugin to log test execution details directly into the console.

   Answer: C. Use the JUnit reporter and configure CI to store and display logs from the XML output.

   Cypress supports logging test execution details through reporters like JUnit, which can be configured to generate XML output. This XML output can be stored and displayed by CI systems to provide visibility into test execution logs. Other options are incorrect because they do not directly address the logging setup in CI for Cypress tests.

3. How does Cypress Cloud track flaky tests?

   1. Cypress Cloud uses the number of test retries configured in the cypress.config.js file to determine flakiness.
   2. Flake detection in Cypress Cloud is based on the duration of each test, with longer tests being flagged as flaky.
   3. Cypress Cloud does not support flake detection and relies on manual inspection of test results for identifying flaky tests.
   4. Cypress Cloud tracks flaky tests by analyzing test outcomes across parallel runs and identifies tests that fail in one run but pass in subsequent retries.

   Answer: D. Cypress Cloud tracks flaky tests by analyzing test outcomes across parallel runs and identifies tests that fail in one run but pass in subsequent retries.

   Cypress Cloud uses historical data and parallel run results to detect flaky tests by identifying tests that fail initially but pass on retries. This allows for accurate tracking and reporting of flake rates. Other options are incorrect because they either describe unrelated features or misrepresent how flake detection works.

4. In a large project with multiple test suites, how can you best manage and control the execution order of tests for different run types such as smoke, regression, or end-to-end testing?

   1. Use the default Cypress test execution order based on the alphabetical order of spec files.
   2. Use the built-in Cypress test runner to manually reorder tests within a spec file.
   3. Use the @cypress/grep plugin to tag and filter tests for different run types (e.g., smoke, regression).
   4. Use the testIsolation feature to control the execution order of tests in parallel runs.

   Answer: C. Use the @cypress/grep plugin to tag and filter tests for different run types (e.g., smoke, regression).

   The @cypress/grep plugin allows you to tag tests with specific labels and run subsets of tests based on those tags. This provides fine-grained control over the execution order and grouping of tests, which is essential for managing large test suites efficiently. Other options are either incorrect or irrelevant to the specific question context.

5. Which statement accurately describes how Cypress handles spec files during parallel runs?

   1. Test isolation is disabled by default in Cypress 12+ to improve performance.
   2. Parallel runs execute individual tests in parallel, not spec files.
   3. Spec files are run in the same browser context to reduce resource consumption.
   4. Each spec file is run in a fresh browser context, and test isolation is enabled by default in Cypress 12+.

   Answer: D. Each spec file is run in a fresh browser context, and test isolation is enabled by default in Cypress 12+.

   In Cypress, when running tests in parallel, each spec file is executed in a fresh browser context to ensure test isolation and prevent state carry-over between specs. This behavior is enabled by default in Cypress 12+ due to the testIsolation feature. Other options may not correctly describe the behavior of parallel runs or may be based on incorrect assumptions about how Cypress executes spec files.