Question 295199 in Reactjs Question posted in
The new location for the React Documentation can be found here.

Reactjs – Cypress doesn't recommend conditional testing, what are the other ways to achieve this without writing flaky tests

We have a table in our application:
if the table length is more than 5 it shows the pagination and if the length is less than 5 it doesn’t
Cypress doesn’t consider it a good practice to use conditions in the Cypress test.
what are the best practices to handle this situation?

If I write a test case for pagination then when it doesn’t have enough data and doesn’t show the pagination on the table. then the table with paginations fails.
And when we have enough data and it shows the pagination then the test without pagination gets failed.

I’ve studied Cypress docs about conditional testing in detail but didn’t find the solution here: https://docs.cypress.io/guides/core-concepts/conditional-testing#What-youll-learn

I studied Cypress docs about conditional testing in detail but didn’t find the solution.

I tried to pass a callback in should() and then() for chaining purposes but still not luck.

Tags:

2

Answers


  1. 0

    I’d recommend using a strategy that makes your test not require a "conditional" check. I think the easiest solution would be to use cy.intercept() to stub your network request and force your test to have (or not have) pagination.

    describe('tests', () => {
  it('tests pagination', () => {
    cy.intercept('/my-url', { fixture: 'pagination.json' });
    cy.visit('/my-website');
    // my tests for pagination
  });

  it('tests no pagination', () => {
    cy.intercept('/my-url', { fixture: 'no-pagination.json' });
    cy.visit('/my-website');
    // my tests for no pagination
  });
});

    The above sample sets the intercept in both cases, using the fixture option to populate a stub. There are a number of alternative ways to achieve this, all highlighted in the cy.intercept() documentation.

    Why Should I Stub?

    Your tests are validating that given some condition (specifically, when there is a certain amount of data), you are given pagination options (or the opposite.) That’s it – the tests aren’t testing that the data from the back end is correct, or any of the other factors associated with the test. So, strip out all of the factors you don’t control (in this case, the API response), so that your test is completely within your control.

    But doesn’t that leave me with a gap in coverage? What if the API changes, or goes down?

    It does leave you with a gap in coverage. But by relying on that data response in these tests, you’re setting yourself up for frustration. You should have tests that specifically target those other gaps, so that you have assurance that those specific conditions are met. These tests, though? They’re just looking at how the pagination UI works – if I have X responses, do I get the correct pagination UI?

    Addendum: It is possible to incorporate a "conditional" aspect into your tests, and it may even be preferable in certain cases. I won’t go into how you could solve for that using JQuery or using cy.intercept() just to listen to the network response. But on the whole, tests should be determinant and as atomic as possible. Including outside factors that can disrupt your confidence in your tests will do just that – lower your confidence in your tests.

    Login or Signup to reply.
  2. 0

    You as If I write a test case for pagination then when it doesn’t have enough data – but how do you get into that situation?

    When you perform a cy.visit() to the page the data displayed shouldn’t be random, it should be in a state that you know at the start of the test.

    See ARRANGE-ACT-ASSERT: A PATTERN FOR WRITING GOOD TESTS

    Arrange-Act-Assert is a great way to structure test cases. It prescribes an order of operations:

    1. Arrange inputs and targets. Arrange steps should set up the test case. Does the test require any objects or special settings? Does it need to prep a database? Does it need to log into a web app? Handle all of these operations at the start of the test.
    2. Act on the target behavior. Act steps should cover the main thing to be tested. This could be calling a function or method, calling a REST API, or interacting with a web page. Keep actions focused on the target behavior.
    3. Assert expected outcomes. Act steps should elicit some sort of response. Assert steps verify the goodness or badness of that response. Sometimes, assertions are as simple as checking numeric or string values. Other times, they may require checking multiple facets of a system. Assertions will ultimately determine if the test passes or fails.

    If you find you need conditional testing, then you have skipped the Arrange part. of the test.

    Specifically, with respect to the table example, pagination is a feature you would want to test so you would have two or more scenarios

    • When I have a table with less than 5 items, I should see that pagination controls are disabled.

    • When I have a table with more than 5 items, I should see that pagination controls are enabled.

    • When I have a table with more than 5 items, I should be able to click the pagination controls.

    Each scenario uses a different Arrange step, so there is no need for conditional testing.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search