Testing

The Technical Bits

Behavior-Driven Testing

Both Cypress and Jest/Vitest use behavior-driven concepts.
Behavior-driven Development (BDD)
"it should ..." sentences label each test rather than method names
Usually has Given (preconditions), When (initial actions), and Then (expected results) structure
A testing framework collects the tests, runs them, counts successes and failures, and reports results

Describing Tests

Label tests with descriptive texts rather than function names

describe('sorting the list of users', function() {
  it('sorts in descending order by default', function() {
    ...
  });
});

Expected Values

Matcher methods on expect() describe expected results

expect(isLeapYear(2000)).toBe(true);

Unit Testing Concepts

Test a unit, i.e., a single class or component, not the whole system.
Tests are independent. They can run in any order or even in parallel.
Common setup actions, e.g., connect to test DB, are in a setup method run before every test.
Common cleanup actions are in a tear down method run after every test.

Setup / teardown

beforeEach / afterEach

describe("readFileContent function", () => {
 beforeEach(() => {
    // Runs before each test
    vi.resetAllMocks();

    // Set up default mock behavior for fs.readFile
    fs.readFile.mockResolvedValue("Mocked content");
  });

  it("should successfully read the content of a text file", async () => {
    const content = await readFileContent("text-content.txt");

    // Check that fs.readFile was called once
    expect(fs.readFile).toHaveBeenCalledTimes(1);
    expect(fs.readFile).toHaveBeenCalledWith("text-content.txt", "utf-8");

    // Verify that the returned content matches the mock
    expect(content).toBe("Mocked content");
  });
});

source

Jest / Vitest

Jest testing framework -- installed automaticaly by create-react-app
Vitest -- Vite-compatible version of Jest
React Testing Examples -- many examples of testing components

Cypress

Home page
Emphasizes simple to write and read tests
Only works with web apps
Talks to the app. Does not directly call your React functions.

Unit (Jest/Vitest) vs E2E (Cypress)

E2E	Unit
E2E tests interact with the app interface, just as a user does.	Unit tests interact with the app code. They call app functions, look at app data structures.
E2E tests can slow, waiting for server, browser, and network responses.	Unit tests should blazingly fast, fractions of a second.
A well-tested app will have hundreds of E2E tests.	A well-tested app will have thousands of unit tests.

What to Unit Test

Code that sends data to a database
- bugs here can corrupt all data permanently
Code with AND / OR / NOT logic on two or more variables
- automation needed to test all combinations on all changes to code
Behavior involving several steps and/or change in time and space

What Not to Unit Test

Private internal functions
Simple setters and getters
Logging functions like toString

Tips

Skip snapshots.
Write resilient tests. Minimize dependence on UI details. Use data-testid to mark tested elements.
- Making your UI tests resilient to change.

Unit Tests: The Challenge

Unit tests
- should be numerous, fast, automated
- should test only the unit, not other classes
- should not cross module boundaries
So how can you unit test
- network calls
- database updates
- modules that don't exist yet

Solution: Mock Objects

Mocks let you test that code calls another object correctly and uses the results correctly
- A mock is a spy that records calls to it
- A mock is a stub that imitates an object's responses
Mock libraries provide tools for making mocks in just a few steps
Mocks are also very useful for "Plan B" demos!!

Mocking Modules

Mocking Services with Vitest -- my guide

Readings: Mock Objects

Mocking functions and modules with Vitest
vitest + mocks = superpower
Jest Docs: Mock Functions
Common tricky cases:
- Time
- Space
Mock Function Custom Matchers
Fowler: Mocks aren't stubs

Thanks to Hakim El Hattab for RevealJS