Automated Testing

[coryhouse]

My Cypress vs Playwright Benchmark

102 tests in Chrome

On Jenkins, single core:
Cypress: 4:30
Playwright: 1:58

M1 MacBook Pro (multi-core):
Cypress: 2:15
Playwright: 20 seconds!

Best Practices

• Jest and Cypress best practices
• javascript-testing-best-practices
• ui-testing-best-practices
• awesome-regression-testing
• Tag tests in their names such as #E2E, #Integration, etc. Then can filter the list as needed by "tag"
• Use at least 2 levels of describe nesting to group related tests and provide useful names in test output. User -> add user -> happy path -> returns id and User -> add user -> non-admin -> throws error
• Found a bug? Write test first.
• Unit testing is overrated. My summary
• Fail test on console log or error: https://github.com/ValentinH/jest-fail-on-console or https://github.com/tkrotoff/throw-on or https://twitter.com/housecor/status/1622595548267319297

Data

• Write atomic tests. Write the data you need for each test, then remove it. Avoid using the same data for multiple tests if the data can be changed.

Principles

• What a unit test shouldnt do
• Write tests that mimic how your users interact with your code
• Mindset: "Zero One Many Lots Oops" - Helps consider edge cases.
• Focus on use cases, not code coverage
• 5 questions every test should answer:
  • What is the unit under test (module, function, class, whatever)?
  • What should it do? (Prose description)
  • What was the actual output?
  • What was the expected output?
  • How do you reproduce the failure?

Programmer tests should - Approach comparison

• Minimize programmer waiting.
• Run reliably.
• Predict deployability.
• Respond to behavior changes.
• Not respond to structure changes.
• Be cheap to write.
• Be cheap to read.
• Be cheap to change.

More general advice

• Test both black box (purely on specs) and white box (look at the implementation and let that inform the tests you write). White-box-testing can improve test coverage, by better testing edge cases. 
• Mindset: "This is so important, that we have to build an automated test suite for it. I don’t trust human testers to do the job."
• Automated tests minimize faulty assumptions. They're a safety net for refactors later when the programmer doesn't know about all the previous assumptions and verbally communicated requirements.
• Store related things together. So keep tests alongside the system under test.

"Write tests. Not too many. Mostly integration." - Guillermo Rauch

Automated Testing

• Frameworks (Mocha, Jasmine, Tape, Jest, AVA)
• Jest
  • npm i @types/jest to get autocomplete. Thread
  • Expect Methods
  • Mocking dependencies - Also, consider using msw to mock in both app and tests
  • Snapshot testing - Useful for regression protection. Assures output doesn't change for a given input. So useful for components, mock API responses, to alert if anything changes after upgrading dependencies, or code that you want to refactor that's not currently under test. But NOT useful for TDD. Also not as good as visual tests (Percy/Chromatic) for UI due to false negatives. ANY markup refactor breaks the snapshot.
    • Inline snapshots (Prettier required)
    • Focused / Partial snapshots
    • toThrowErrorMatchingSnapshot
    • Snapshot diffs
    • Or use Enzyme's find to snapshot a portion of render's output.
    • Or consider html-looks-like
    • Some critiques and alternatives
  • Config and Enhancements
    • jest-extended for more assertions
  • Use .each for multiple values per test or try jest-in-case
  • Options for Visual Jest output

Cypress vs Playwright differences

• type -> fill
• cy -> page
• Add await
• get -> locator
• it -> test
• cy.viewport ->
• cy.scrollIntoView -> Playwright does automatically
• Testing lib queries have shorter names on Playwright, and getBy* doesn’t assert by default.
• (should.not.exist) -> tohavecount(0)
• In Playwright, search in section by chaining off the parent’s locator.
• Playwright it’s easy to forget to await.
• describe vs test.describe

General Structure and Practices

• The Test pyramid is a classic, but there are many more types of testing.
• Arrange, Act, Assert
• Wrap in describe blocks to arrange
• Test the public API. Avoid testing implementation details.
• Leverage the same static mock data used for your mock API. Or for more variety, consider using Faker/Chance.
• When testing creates/update/deletes, make each test atomic. Write the data you want to manipulate.
• Consider tagging tests so related tests can be run in isolation. (Use filter tests by name)
• Create a centralized render function that handles React Router, Redux providers, etc.
• Custom render wrapper for each component with getters for each input
• When you have a jest mock function, you should use toHaveBeenCalledTimes and toHaveBeenCalledWith. Even if it's called only once, you want to make sure that it's called no more or less than one time. And note that order matters

React libraries

• react-dom/test-utils (primarily useful for act and simulate, though RTL wraps act and has fireEvent, which are alternatives)
  • act and Simulate are the most useful pieces. For DOM queries, Enzyme and RTL below are better.
• Enzyme
  • Many examples and tips for configuring Jest custom serializer to serialize Enzyme snapshot tests without needing to call toJson
  • Use MDN's shallowUntilTarget to shallow render down to a target component. Useful when testing a component wrapped in HOC. More info and related Enzyme feature request (With this shallow rendering approach, it is now possible to test UserProfile in isolation yet still dispatch Redux actions like a real application.)
• React-testing-library
• React hooks testing library for testing your custom hooks. Or can create a component that uses your hook and then test your component.

Testing Library Tips

• Prefer queries in their suggested order Query the accessibility object model
• How to test a table
• Learn (and target) accessible names
• Common Mistakes
• Use Jest-dom
• Configure ESLint with npm i -D eslint-plugin-testing-library eslint-plugin-jest-dom
• To query within an element/container, use within. Example and here

Cypress Tips

• Check a11y https://github.com/mfrachet/cypress-audit or https://www.npmjs.com/package/cypress-axe
  3 ways to handle login:
  

More broadly, don't use the UI to build up state for each test. Instead, set it.

For example, don't actually run real login for each step. Instead, simulate it:

• Can write Cypress "unit" tests against Storybook stories too
• Review Cypress Real World App
• Best practices from docs
  • Reset before tests for reliability.
  • localStorage and cookies are cleared before each test automatically. So don't reset in tests.
• Mastering UI Testing slides
• cypress-example-realworld - Real world app with many Cypress tests
• eslint-plugin-cypress protects from common mistakes.
• eslint-plugin-no-only-tests - protects from accidentally committing tests with it.only.
• Disable video (useful when running the CI-oriented run command locally)
• Use Cypress Testing Library so you can write accessible "testing library" style queries in Cypress.
• Sometimes you'll need to force a click if the element is styled in a way that Cypress thinks hides it: cy.getByLabelText("Select role for gsparks1").click({force: true });
• Keep the dev tools open as the tests run so you can see errors and warnings from React (such as calling setState on unmounted components or invalid propTypes)
• Export strings from component to avoid copy/pasting strings between tests and components.
• Use subject to query for an element inside a parent
• Create plain functions for repeated code in one file. Use custom commands for repeated code in multiple files. Declare TS Types for custom commands.
• Add skip and only to the test runner

  it.only("should find 630 users when filtered by role of Salesperson or None", () => {
    cy.getByLabelText("Filter by Role")
      .click()
      .then(subject => {
        cy.getByLabelText("Salesperson", { container: subject }).click();
        cy.getByLabelText("None", { container: subject }).click();
      });
    cy.getByText("630 users");
  });

Instructions for downloading Cypress if corp network is blocking:

1. Go to: https://download.cypress.io/desktop/4.2.0?platform=win32&arch=x64
   to download the cypress package.
2. Copy the downloaded zip file to c:\temp
3. Run the command (In a non powershell command line window):

set DEBUG=cypress:cli && set CYPRESS_INSTALL_BINARY=C:/temp/cypress.zip && npm install cypress
in the VSCode terminal or a cmd window

4. Get the last cypress package run the command:
   npm i @testing-library/cypress

Cypress issues

Cypress isn't perfect.

• Keyboard tab key isn't supported, though you can use a plugin or create a custom command.
• Can't switch in/out of iframes.
• Doesn't support hover.
• Lacks support for some other keyboard events
• Strips content security policy headers

Testing Different File Types

• Stateless components
• Instance methods
• Extracting to pure functions
• Extracting setState / functional setState
• Use the object builder pattern to simplify test setup, and the component template pattern (useful for testing React components and Storybook)
• Redux
  • Actions
  • Reducers
  • mapStateToProps (extract to pure func / selector)
  • Connected components
  • Store (integration test)

In browser testing / Integration Testing

• Cypress
  • Cypress vs Selenium
  • Create custom "app actions" API to speed Cypress test initialization. Shorter post here
  • Debug on CI via https://github.com/flotwig/cypress-log-to-output
• Playwright - A fork of Puppeteer created by Microsoft, to focus on automated testing. A short comparison of Playwright vs Cypress. (Note that Cypress now supports multiple domains and webkit, so the post is outdated. Here's another (Playwright vs Cypress post. Note that Playwright is faster than Cypress. If you are a beginner with testing and are looking for ease of installation and usage with solid docs, then Cypress is the way to go. However, if speed matters more (it's faster, it even runs tests in parallel locally, and you can run tests against multiple browsers at the same time), you need hover or tab support, you prefer Playwright's traditional JS approach (instead of Cypress' chaining), or you need Playwright's multi-tab support, then it's the right choice.
• Convert Cypress to Playwright
• Selenium
  • Wrappers like Nightwatch or Katalon
• TestCafe
• Webdriver.io - Used by Cerner. Webdriver vs Cypress
• Codecept.io
• Scenario Testing (use UI to tell a mock API what to return)

Contract Testing (aka Consumer Driven Contract Testing)

Overview: https://www.linkedin.com/pulse/api-contract-testing-visual-guide-peter-thomas/

Test the client/server contract. Assure the API provides the expected responses, via tests. Here's why it's useful.

Tools:

• Pact
• url-content-changes-checker
• Even simply Jest snapshots (to store the expected responses from each APIs)

Benefits:

1. Can reveal unused interfaces - throws an error when there's unused provider code. If no apps are consuming it, obviously the code can be deleted from the provider (the API).

Visual Testing

• Good examples of why visual testing is useful
• Many options via Storybook
• Percy
• Chromatic
• Jest image snapshot https://github.com/americanexpress/jest-image-snapshot
• Happo
• Applitools with Cypress
• Awesome regression testing list

Performance Testing / Monitoring

• https://calibreapp.com/

Property Based Testing

Generate valid random values and feed to tests. e.g. Pass random strings and ints to a func that accepts a string and int.

• jsverify , Test Check, Fast Check

Validation Testing

https://ealush.com/vest

Mutation Testing

Change code and if it doesn't fail, that means you have holes in your test coverage.

• Stryker

Fuzz Testing / Randomized Testing / Test Generation (like Pex for C#, or QuickCheck which popularized the idea)

• TestCheck
• fast-check
• jsfuzz
• jsverify
• Medium post
• https://docs.microsoft.com/en-us/visualstudio/test/intellitest-manual/test-generation?view=vs-2019

Recommended Reading

Testing React components with Jest and Enzyme
Node and JS Testing Best Practices