NO MORE FLAKY TESTS! TALKING ABOUT TESTING WALMYR LIMA E SILVA FILHO

No content

But what about that test that passed locally on your computer, and when it started running in the continuous integration pipeline, it started failing (sometimes?)

A FLAKY TEST IS LIKA A GRANADE... Waiting to explode.

MY DEFINITION OF A DETERMINISTIC TEST Given the same initial system conditions, when a test is run with the same inputs, it will ALWAYS return the same result.

MY DEFINITION OF A NON-DETERMINISTIC TEST Given the “same” initial system conditions, when a test is run with the same inputs, it returns DIFFERENT RESULTS.

“Flaky tests are more harmful than no tests at all”

SIDE EFFECTS OF A FLAKY TEST SUITE Decreases confidence in tests Reduces confidence in the team Increases the number of unfound bugs Increases debugging time Increases software engineering costs Increases the stress level of those involved Increases delivery time Decreases the perceived software quality

FOR WHAT REASONS CAN TESTS BE (OR BECOME) NON-DETERMINISTIC? Shared environment Manual and automated tests running against the same environment. Rendering order cy.get().first() vs. cy.get().should(‘have.length, n).first() Waiting times (network) cy.wait(10000) vs. cy.wait(‘@alias’) Local vs. CI Different computing resources Component state Example: Disabled button Not visible field Animations/transitions The Cypress way: cy.get(‘button’).should(‘be.e nabled’).click() Lack of tool knowledge cy.visit() cy.intercept().as(‘alias’) cy.wait(‘@alias’) vs. cy.intercept().as(‘alias’) cy.visit() cy.wait(‘@alias’) Dependency between tests describe(‘Test suite’, () => { it(‘visits the page’, () => { cy.visit(‘/’) }) it(‘checks the title’, () => { cy.get(‘h1’) .should(‘be.visible’) }) }) Parallelism Data creation that cannot be repeated Tests using shared data API limitations

TEST RETRIES Use as a way to identify non-deterministic tests. Not as a way to mask them.

DIFFERENT WAYS to “burn” tests before making them part of the “official” test suite

Cypress & Lodash context('Cypress._', () => { Cypress._.times(3, () => { it('runs', () => {}) }) })

@cypress/grep // newTest.cy.js it('new test case', { tags: '@burn' }, () => { ... }) // And in the command line terminal, run: cypress run --env grepTags=@burn,burn=10

Coming soon to the Cypress Cloud CYPRESS BURN-IN

WHAT TO DO WHEN ENCOUNTERING A FLAKY TEST? Here are some suggestions. 01. Identify the root cause and fix it immediately 02. Quarantine 03. Rewrite or move the test to another level (e.g. component instead of e2e)

WHAT NOT TO DO WHEN ENCOUNTERING A FLAKY TEST? Here are some tips on what not to do. 01. Don't ignore flaky testing 02. Don't use something like cy.wait(Number) 03. Don’t just rely on retries (you’ll just be “sweeping the dust under the rug”)

WE DO NOT ACCEPT FLAKY TESTS! Trust is everything, and just as you don't like the phrase “it works on my machine,” understand that there is no point in passing the test just on your machine. Automated tests must be deterministic and also pass in the continuous integration environment.

CONTENT SUGGESTIONS https://medium.com/the-making-of-whereby/the- importance-of-dealing-with-flaky-tests- 1b69145dee0f#.g2p671vvx https://dev.to/walmyrlimaesilv/how-to-run-a-test- multiple-times-with-cypress-to-prove-it-is-stable-3c0k https://youtu.be/SK2D18m52Cs?si=dJkeMeYTi8R76325 https://cypress.io/blog/tag/flake https://docs.cypress.io/guides/cloud/flaky-test- management

CYPRESS, FROM ZERO TO THE CLOUD

QUESTIONS?

THANKS! TALKING ABOUT TESTING HTTPS://WALMYR.DEV