"It wasn't long before I discovered TDD and how it could help me have a simpler, quieter, calmer life."
Chapter 03 - Loading Data into a Route
Template for testing SvelteKit server-side page load functionality
import{describe,it,expect}from"vitest";import{load}from"./+page.server.js";describe("/birthdays - load",()=>{it("returns a fixture of two items",()=>{constresult=load();expect(result).toEqual({people: [{name: "Hercules",dob: "2021-01-01"},{name: "Athena",dob: "2021-01-02"},],});})-[];});
Chapter 04 - Saving Form Data
Template for testing SvelteKit server-side form actions functionality
// mocking form data request objectconstcreateFormDataFromObject=(obj)=>{constformData=newFormData();Object.entries(obj).forEach(([key,value])=>{formData.append(key,value);});returnformData;};exportconstcreateFormDataRequest=(obj)=>({formData: ()=>newPromise((resolve)=>resolve(createFormDataFromObject(obj))),});
Use expect.hasAssertions() to require expect assertions to be called in a catch of a try-catch block
Chapter 11 - Replacing Behavior with a Side-By-Side Implementation
side-by-side implementation - is a way to use tests to replace the existing code while ensuring the test suite remains on Green
In Vitest, a spy is created by calling vi.fn
Incredibly confused by this chapters implementation, but going to brush it off and continue forward
Chapter 12 - Using Component Mocks to Clarify Tests - 15 pages
The number-one rule when using component mocks, and test doubles in general, is to avoid building any control logic into them.
mockReturnValue and mockResolvedValue always return fixed values
Avoid setting up a test double in a beforeEach block
Hand-rolled component stubs rely on Vitest's vi.mock function and __mocks__ directory
JSON.stringify is a handy method to use in component mocks when you just want to verify that the correct prop structure is passed to a mock from its parent
BIG NEGATIVE WITH MOCKING COMPONENTS:
it's challenging to keep the mock aligned with real implementations.
If needed, use svelte-component-double package to mock components and gain access to useful custom matchers: toBeRendered and toBeRenderedWithProps
Avoid component mocks if possible because they added complexity to the testing suite
Chapter 13 - Adding Cucumber Tests - 10 pages
Cucumber tests are not written in JavaScript code. They use a special syntax known as Gherkin within feature files
Given, When, Then
The Gherkin syntax allows for product features to be specified by non-coders in a more human-friendly format, but eventually code re-enters the scene within the step definitions
Semi-useful to now, but feels just like Playwright E2E tests with more steps.
Chapter 14 - Testing Authentication - 10 pages
Chapter 15 - Test-Driving Svelte Stores - 5 pages
vi.useFakeTimers and vi
writable([])
Three things to test:
Setting the initial value
Displaying the value (1. On Initial load and 2. On update)
Updating the value
Chapter 16 - Test-Driving Service Workers - 10 pages