Share
Embed
Transcript
21 slides
-
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?) -
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. -
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 -
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.