Your project does what it promises: the domain enforces the rules, the data survives a reload, the application talks to an API and works offline. And now comes the uncomfortable question, the one that separates a demo from a product: how do you know it still does tomorrow? Because you have migrations that can silently corrupt data, synchronization with races that only appear on a bad network, and views that can retain memory when you navigate — three things you cannot see by looking at the screen and that, when they fail, fail on somebody else's device. In this lesson you bring everything you learned in Module 8 into your own project, but with an important difference: there the tests were handed to you written, and here you have to decide what to test, at which level and how far. You will see how to define a testing strategy with the pyramid applied to your concrete modules and a reasoned rather than cosmetic coverage target; how to test the domain exhaustively with parameterized tests of the fifteen rules; how to test the data layer with doubles, fake timers and a fake fetch, including the migrations and the queue; how to test the view by querying by role and also the keyboard walkthrough; how to choose three end-to-end journeys and why no more; how to set up complete continuous integration with a performance budget; how to debug three failures that are genuinely going to appear in your project, with the technique of reproducing first and writing a failing test; how to automate and complement accessibility testing; and how to measure your project against the Nómada Tasks baseline. By the end you will have the full suite green in CI plus the accessibility and performance reports.

1. The testing strategy: deciding what is tested and where
2. The pyramid applied to your concrete modules
3. A reasoned coverage target, not a cosmetic one
4. Testing the domain: the fifteen rules parameterized
5. Testing the transitions and the edge cases
6. Testing the data layer with doubles and fake timers
7. Testing the migrations and the offline queue
8. Testing the view with jsdom and Testing Library
9. Testing the keyboard walkthrough
10. Three end-to-end journeys, and why no more
11. Continuous integration with GitHub Actions
12. Lighthouse CI and the performance budget
13. Debugging your own project: the method applied
14. Failure 1: the migration that corrupts data
15. Failure 2: the race condition during synchronization
16. Failure 3: the memory leak when navigating
17. Accessibility testing: automated and manual
18. Measuring your own project's performance
19. Flaky tests
20. Common Mistakes and Tips
21. Exercises
22. Conclusion

Before you write a single further test, three questions need answering. Writing them in docs/testing-strategy.md is half an hour that saves weeks of badly placed tests.

Question 1 · What must never fail?

In Orbita, the answer is concrete: the business rules and the persistence. A button two pixels to the left is a cosmetic defect; a migration that loses somebody's tasks is the death of the product. Tests concentrate where failure is catastrophic, not where they are easy to write.

Question 2 · What changes often and what does not?

What changes a lot — the layout, the wording, the CSS classes — must not be coupled to the tests, or every visual tweak will break twenty tests that detect no real failure. What changes little — the rules, the contracts — can be tested thoroughly with no maintenance cost.

Question 3 · How much does each test cost and how much is it worth?

The operational conclusion: many unit tests, a fair number of integration tests, very few end-to-end tests. It is not an aesthetic preference; it is a direct consequence of the table.

The decision rule that resolves almost every case:

Test at the lowest level that catches the failure you are worried about.

If you are worried that R13 does not block closing, that is a domain unit test: no browser needed. If you are worried that the button is not disabled when it should be, that is DOM integration. If you are worried that creating a task, reloading and seeing it does not work end to end, that is end to end. Testing R13 from Cypress is a hundred times slower and gives the same information.

The generic testing pyramid does not help much. This one does, because it names your files:

Rough total: about 250 tests, of which three are end to end. Nómada Tasks had 124 tests and 3 journeys with fewer features; the order of magnitude is consistent.

Two observations about this table:

• rules.js is not tested directly. They are constants. A test checking that MAX_HOURS === 40 verifies nothing: it rewrites the value somewhere else. What gets tested is that the rule is enforced, and that happens in task.js.
• The view-to-domain ratio is roughly 1 to 2. If your project had more view tests than domain tests, it would be a sign the logic is in the view — exactly what the architecture in 11-01 was meant to prevent. The distribution of your tests is a diagnosis of your architecture.

Coverage measures what percentage of the code runs during the tests. It is a useful and a dangerous metric in equal parts, and it is worth understanding why.

What coverage does tell you: which code is not tested at all. A 0 % in migrations.js is a real alarm.

What coverage does not tell you: whether what is tested is well tested. This test gives 100 % coverage and verifies nothing:

That is why a single target for the whole project is a bad target. The sensible thing is per layer, and with judgment:

The justification for each threshold, which is what you have to write in your strategy:

And the metric that really matters is not the percentage: it is rule coverage. Keep a table in docs/testing-strategy.md:

Fifteen rules × three cases = forty-five minimum tests. That table is a far more honest target than "85 % coverage", because you cannot pass it without verifying something.

Parameterized tests are the natural tool for rules, because a rule is a statement about a set of cases.

Four decisions in this table that make it valuable:

1 · The table reads as a specification. Anyone reading it knows exactly what the model accepts and rejects, without reading the Task code.

2 · Every rule has its exact boundaries. For R3: 0 no, 0.5 yes, 40 yes, 40.1 no. Developer bugs live in the > that should have been >=, and they are only caught by testing the exact boundary value.

3 · error.field is checked, not just the type. That piece of data is what lets the form mark the right field (11-02). If it is not tested, one day somebody writes field: 'hours' instead of 'estimatedHours' and the form silently stops highlighting anything.

4 · There are type cases, not just value cases. '12' as text and NaN are the ones that slip through naive validations like if (hours > 40). With NaN, that comparison is false and the value gets through.

The R14 case deserves a special test, because its invariant is not about a value but about the structure:

The R6 transition matrix is tested in full, as in 11-02. But there are three kinds of edge case that are systematically forgotten and worth enumerating:

Numeric boundaries. For every comparison in your domain, test the exact value, one below and one above:

Collection boundaries. For every function that takes a list:

Time boundaries. The ones that produce the most bugs and get tested the least:

The second row is the one that breaks almost every homegrown ISO-week implementation, and it directly affects R15 and the workload report. If your project uses weeks, this test is not optional.

And a case that only appears in projects with trees: the degenerate tree. A task with 200 subtasks at a single level, and a chain of 3 levels with one leaf at each. The two exercise different paths through your recursion.

Here everything from 08-04 applies. The governing rule: you replace what is slow, non-deterministic or external; never the logic you are testing.

The throw new Error('unexpected fetch') detail is important: one extra call you did not expect is a failure you want to see, not something that should return undefined and produce a confusing error later on.

The two assertions about calls.length are the heart of these tests. Without them, both would pass even if the retry logic were broken.

advanceTimersByTimeAsync and not advanceTimersByTime. The async version also drains the microtask queue between advances, and without it the intermediate promises never resolve and the test hangs. It is one of those details that cost you an afternoon the first time, and it makes complete sense in the light of 05-07: microtasks and timers are different queues.

Remember to restore the real timers. A jest.useFakeTimers() left active contaminates subsequent tests with apparently random failures. Put it in a global afterEach.

You already saw the six base tests in 11-03. Add these three, which cover what goes wrong in practice:

The second one is a performance test inside the suite, and here it is justified: the migration happens at startup, blocking the first paint. A two-second migration wrecks the LCP from the 11-01 budget, and that failure only shows up with real user data. Putting a threshold in the test prevents it.

The third test is the one that prevents the duplicate from section 13 of 11-03, and it is impossible to check by hand reliably. It is the perfect example of a failure that only an automated test catches.

The principle from 08-05, worth remembering because it changes everything:

Test the way a person uses the application, not the way it is built inside.

In practice, that means querying by role and by accessible text, never by CSS class or structure.

The double benefit: the test survives a CSS class change, and it verifies accessibility as a bonus. If getByRole('button', { name: /create/i }) finds nothing, it is because your button is not a button or has no accessible name — and that is a real defect a querySelector would have hidden.

Notice that half of these tests verify accessibility and experience requirements — semantic list, text in addition to color, count announcement, empty state with a way out — that you wrote as acceptance criteria back in 11-01. The circle closes: story → criterion → test.

This is the part almost no portfolio project has, and the one that most impresses in a review.

The three cover the three most common focus bugs: not entering on open, not returning on close and escaping while open. If you use <dialog> with showModal(), all three pass with almost no effort — which is exactly the argument from 11-02 about using the right element.

A warning about jsdom: jsdom implements <dialog> incompletely in some versions, and it does not compute styles, so it cannot verify visibility or contrast. Keyboard tests in jsdom cover the logic of focus; genuinely verifying that you can see where you are is a manual or end-to-end check.

End-to-end tests (08-06) are the most valuable per test and the most expensive per test. That double condition dictates the strategy: few and very well chosen.

The selection criterion, in one sentence: choose the journeys that, if they broke, would make the product useless. For Orbita:

Journey 1 · The complete lifecycle of a task.

This journey covers, all at once: creating with validation, the tree, R13 genuinely enforced from the interface, the error message, the complete transition and persistence after a reload. One journey, six risks.

Journey 2 · Filter, share the filter and view the report. It covers shared state, the URL as the source of truth, the workload calculation and the empty state.

Journey 3 · Work offline and recover. It covers the queue, persistence and reconciliation:

That final should('have.length', 1) is the duplicate test: if idempotency fails, two appear.

Why exactly three. With three journeys you cover the three systemic risks — the main flow, shared state and resilience — in about 30 seconds of execution. With twenty you would have five minutes of CI, weekly flaky failures and a maintenance load that would end with somebody disabling them. A disabled end-to-end suite is worth zero, so the right number is the maximum you can keep permanently green. Three is that number. Nómada Tasks also had three, with fewer features: the ratio holds.

Continuous integration runs npm run verify on every push, on a clean machine. That "clean machine" is half the value: it catches the "it works on my machine" cases caused by an uncommitted file or a global dependency.

The file's decisions, one by one:

Branch protection. CI is worthless if you can merge while it is red. In the repository settings, mark main as protected and require all three jobs to pass before merging. It is one click that turns a recommendation into a guarantee — the same idea as the ESLint rule from 11-01.

In 11-01 you set the budget. Here you enforce it automatically.

Four observations:

• numberOfRuns: 3. Lighthouse is noisy; with a single run you would get random failures. Three runs and take the median, exactly the measurement discipline from 09-01.
• error versus warn. What breaks the build is what is in the signed budget; the rest is informative. If everything is an error, you will end up disabling the whole thing on the first difficult Friday.
• resource-summary:script:size at 61440 is the 60 kB budget from 11-01, in bytes. This single line is what stops somebody adding a charting library one day without anyone noticing.
• The three accessibility audits with minScore: 1 — contrast, labels, button names — are the ones that degrade most over time. Demanding perfection on those three is achievable and prevents erosion.

When the budget fails, there are three legitimate ways out and one illegitimate one:

Lesson 08-01 gave you the method. Here it is applied to your own failures, and the important change is that nobody is going to tell you where the problem is.

The procedure, in six steps:

Step 3 is the one almost everybody skips, and it is the most profitable of the six. Writing the test before fixing has four simultaneous benefits:

1. It proves you have understood the failure. If you cannot write the test, you do not know what is wrong: you only have a symptom.
2. It tells you when you are done. Without it, "it seems to work now" is all you have.
3. It prevents recurrence. Bugs fixed without a test come back, and they come back at the worst moment.
4. It documents the odd case. A year from now, that test will explain why the code has that apparently unnecessary line.

Step 4 deserves a nuance. A useful hypothesis is falsifiable and concrete: "the id reaching the PUT is undefined because the server returns _id". A useless hypothesis is "something is going on with the ids". The first is checked with one measurement; the second leads you to poke at things to see if they fix themselves, which is the most expensive form of debugging there is.

The next three sections walk through three failures that are going to appear in your project. They are not made-up examples: they are the direct consequences of what you built in 11-02 and 11-03.

The symptom. A test user (or you, with your old development profile) updates the application and sees the board with the tasks, but they all appear with no assignee and the workload report comes out at zero. There is no error in the console.

Step 1 · Reproduce. The failure does not happen with new data, only with old data. Reproducing it requires the original document — and here the backup from 11-03 pays off:

The old data does have assignees. So the migration is what loses them.

Step 2 · Reduce. To the minimal case: two tasks and one user.

Step 3 · The failing test:

Step 4 · Hypothesis. The byName map does not find 'Iván'. Possible causes: (a) the users are not loaded when the migration runs, (b) the name does not match exactly, (c) the migration order is wrong.

Step 5 · Check with a measurement:

There it is. The two strings look identical on screen and are not equal: one uses the precomposed character í (U+00ED) and the other an i followed by a combining accent (U+0301). It is a classic with data that has passed through different operating systems or browsers.

Step 6 · Fix. By normalizing Unicode on both sides:

And the three generalizable lessons:

1. Matching by text is fragile. Match by identifier whenever possible. If there is no alternative, normalize (normalize('NFC'), trim(), and consider toLocaleLowerCase()).
2. A silent failure is worse than a noisy one. The migration set null without warning. It should count how many assignments it could not resolve and log it: log('migration v2: 6 of 8 assignees unresolved'). A warning would have revealed the bug on day one.
3. The backup saved the investigation. Without it, the original data would have vanished and you would only have the symptom.

The regression test that stays, with the Unicode case made explicit:

The symptom. On a slow network, sometimes — not always — marking a task as done makes it go back to pending a second later. It does not happen on your machine with a fast network. There is no error in the console.

This is the worst kind of failure: intermittent and environment-dependent. And the first rule is not to try to debug it until you can reproduce it at will.

Step 1 · Reproduce. With the Network panel on Slow 3G, it happens one time in three. That is still not enough. To make it deterministic, you have to control the timing:

With a three-second delay, it happens every time. Now it is reproducible.

Step 2 · Reduce. The minimal sequence turns out to be:

The list refreshes with data from before my change and overwrites the optimistic update.

Step 3 · The failing test, with fake timers to make it deterministic:

Step 4 · Hypothesis. The GET replaces the whole list with whatever the server returns, without accounting for local changes still awaiting confirmation.

Step 5 · Confirmed: refreshTasks does store.update({ tasks: fromServer }).

Step 6 · Fix. Three possible solutions, and it is worth seeing why one is chosen:

The three generalizable lessons:

1. An intermittent failure is almost always a race. When something happens "sometimes", look for two asynchronous operations that can finish in different orders.
2. Reproducing requires controlling time. Delaying requests on purpose turns "one time in three" into "always", and that is what makes debugging possible.
3. Any state that is replaced wholesale is suspect. update({ tasks: newOnes }) discards information that may be more recent. Replacing should always be a decision, not the default path.

The symptom. After navigating between board, report and history for a while, the application becomes slow. At first you do not notice; after twenty navigations, every screen change takes visibly longer.

Step 1 · Reproduce and measure, with the protocol from 09-03:

1. Open the Memory panel in incognito mode.
2. Snapshot 1 (baseline).
3. Navigate 20 times between the three screens.
4. Force garbage collection (the trash-can icon).
5. Snapshot 2.
6. Compare by Objects allocated between snapshots.

The result:

Twenty-one live instances of BoardView. There should be one. The 4,812 detached nodes are the DOM of the previous twenty, retained by something.

Step 2 · Find the retainer. In the Memory panel, select one instance and look at Retainers:

The store is retaining twenty subscriber functions, each with its closure over its view and its DOM.

Step 3 · The failing test:

Steps 4 and 5 · The cause. The code was this:

Step 6 · Fix, by keeping every unsubscribe:

The four generalizable lessons:

1. Everything that connects must disconnect. Listeners, subscriptions, timers, observers, sockets. The "push the unsubscribe into an array" pattern turns destroy() into three always-identical lines.
2. A leak is not seen, it is measured. Nobody detects 26 MB by looking at the screen. Without the three-snapshot protocol from 09-03, this is discovered when a user says "it gets slow after a while".
3. It is checkable in a unit test. You do not need the Memory panel to prevent recurrence: exposing subscriberCount and counting is enough. That test takes one millisecond and runs on every push.
4. Add the navigation counter to your checklist. Entering and leaving each screen three times, with the listener counter in view, should be part of closing every increment.

There is a figure worth keeping in mind: automated tools detect around a third of real accessibility problems. They are indispensable and they are not sufficient.

The last two cases — empty state and error state — are the ones nobody tests and where the most violations show up, because they are laid out in a hurry and never reviewed.

And in Cypress, against the real application (which does compute styles, and therefore does detect contrast):

No tool detects that the tab order is absurd, that an alternative text says "image1", or that the flow is impossible to follow without seeing the screen. That is tested by hand, with this list:

About 50 minutes per full review. Do it at the close of each milestone, not at the end.

Point 3 is scary the first time and it is the one that teaches most. Tips for getting started: learn five shortcuts (read everything, next element, next heading, list of links, list of headings), genuinely close your eyes, and try to complete a specific task. What you will almost certainly discover: that your headings do not form a navigable structure, that your icon buttons say nothing, and that when something changes on screen you have no idea.

A milestone deliverable, in docs/accessibility.md:

That document, with its stated limitations, is worth more in an interview than a Lighthouse score of 100. It shows you actually looked.

Apply the protocol from 09-01 to your project: the median of 15 repetitions after 5 warm-up runs, 4× CPU, Slow 4G network, incognito, same machine.

Generate realistic data first. Measuring with six tasks tells you nothing:

And the results table, with the Nómada Tasks reference alongside:

How to read the comparison honestly, which is the part that matters:

• Orbita is somewhat heavier than Nómada Tasks, and it should be. It has three more screens, a subtask tree, a history and a synchronization queue. Staying within budget with more functionality is the correct result.
• Being under budget is no reason to relax: it is headroom for what is coming. Note the headroom down: 5.9 kB of JavaScript and 400 ms of LCP.
• If you are outside, the table tells you where to look. Every row has its Module 9 lesson: high render() → 09-04; high JS → 09-05; memory → 09-03; INP → 09-02.

And a rule against self-deception: measure in incognito mode, with no extensions and without the dev server. Vite in development serves unbundled modules, and measuring there gives numbers with nothing to do with production. You measure on npm run build and npm run preview.

A flaky test passes sometimes and fails other times with no code change. They are a suite's worst enemy, for one concrete reason: they destroy trust. As soon as people start re-running CI "to see if it passes this time", the tests stop being a signal and become noise.

The causes, with their solutions:

The protocol when a flaky test appears:

1. Never re-run it and move on. That is the habit that ruins suites.
2. Label it and run it in a loop to measure the frequency:

   npx jest --testNamePattern="name" --runInBand --repeat=50
   

3. Isolate the cause with the table above. It is almost always time or shared state.
4. Fix the cause, not the symptom. Adding cy.wait(2000) fixes nothing: it makes the test slower and it will still fail on a slower machine.
5. If you cannot fix it today, mark it with test.skip and open an issue with a date. A disabled, documented test is honest; an active flaky test is corrosive.

And the hygiene rule: run the full suite five times in a row before signing off a milestone. If all five pass, you have a reliable suite. If one fails, you have a flaky test you already know about — and it is far better to know about it now than on a Friday during a deployment.

Testing the implementation instead of the behavior. A test that checks an internal method was called breaks with every refactor without detecting any real failure. Test what goes in and what comes out, or what the user sees. The practical rule: if reorganizing the code internally, without changing behavior, breaks tests, those tests were wrong.

Chasing 100 % coverage. The last few percentage points are usually defensive branches that never run, and forcing them produces artificial tests that add no confidence. Raise the bar where the risk is high — domain and migrations — and accept less where the cost is high and the risk low.

Writing twenty end-to-end tests. They are slow, fragile and flaky. With twenty, CI takes five minutes and somebody will end up disabling them. Three well-chosen ones give almost the same systemic confidence at a fraction of the cost.

querySelector by CSS class in view tests. It couples the test to the layout and verifies no accessibility. getByRole does both things well and fails when your HTML is not semantic, which is valuable information.

Not cleaning state between tests. localStorage, fake timers, fetch doubles and the DOM carry over from one test to the next and produce order-dependent failures. A beforeEach that cleans everything, always.

Using advanceTimersByTime with asynchronous code. It does not drain the microtask queue and the test hangs or fails with no explanation. advanceTimersByTimeAsync and await.

Fixing a bug without first writing the failing test. You lose all four benefits: the proof that you understood it, the completion criterion, protection against recurrence and documentation of the odd case. It is the habit that most separates people who debug with a method from people who poke at things.

Debugging an intermittent failure without making it deterministic first. "It happens sometimes" cannot be debugged. Control the timing, the responses and the randomness until it happens every time; then start investigating.

Re-running CI until it passes. Every time you do it, your suite loses value. Treat every flaky test as a real failure, because it usually is: the race producing the failure in CI exists in production too.

Believing axe is enough. It detects around a third of the problems. A keyboard and twenty minutes with a screen reader find things no tool sees.

Tip · Run the tests in watch mode while you program. npm run test:watch with Jest runs only what is affected by what you just saved. The feedback loop drops from minutes to under a second, and that changes how you work.

Tip · Write the test name as a sentence describing the behavior. 'rejects closing a task with open subtasks', not 'test changeStatus 3'. When it fails in CI three months from now, the name will be all the information you have at first.

Tip · Keep a well-tended test/helpers/ folder. Entity factories, application mounting, fake fetch, data generators. Every minute invested there is multiplied by the number of tests you will write afterwards.

Tip · Add the test count and coverage to the README. "251 tests · 3 E2E journeys · 94 % domain coverage" is an immediate signal of seriousness to anybody looking at your repository, and it reminds you to keep it up.

These exercises are milestone H5 of your project: the full suite green in CI plus the accessibility and performance reports.

Exercise 1 — The strategy and the complete suite.

1. Write docs/testing-strategy.md with: the three questions from section 1 answered for your project, the pyramid table with your modules and their numbers, and the coverage thresholds per layer with their justification.
2. Configure Jest with separate projects: node for the domain and jsdom for the rest, with coverageThreshold per path.
3. Complete the rule coverage table: the 15 rules × (passing case, failing case, boundary case). At least 45 domain tests.
4. Write parameterized tests with describe.each for at least: field validation, the complete transition matrix and the date cases (including week 53).
5. Test the data layer with a fake fetch and fake timers: status codes, selective retries, timeout, cancellation and exponential backoff verified against timings.
6. Test the migrations (at least 9 tests, including idempotency, domain validity and the performance one) and the queue (at least 6, including the idempotency key shared across retries).
7. Test the view with Testing Library, always querying by role or accessible text, including at least three keyboard walkthrough tests (focus entry, focus return, no escape).
8. Write exactly three Cypress journeys and justify in writing why those three.

Exercise 2 — Complete continuous integration.

1. Write .github/workflows/ci.yml with the three jobs: quality, end to end and Lighthouse, with concurrency, the npm cache, needs and artifact uploads.
2. Configure lighthouserc.json with your budget from 11-01 translated into assertions, distinguishing error from warn.
3. Enable branch protection on main requiring all three jobs.
4. Deliberately trigger a failure of each kind and check that CI catches it: a lint error, a broken test, a coverage regression below the threshold, and a bundle size increase above the budget (import a large library and remove it afterwards).
5. Document the CI status in the README with its badge.

Exercise 3 — The three failures, the reports and the baseline.

1. Reproduce the three failures from sections 14, 15 and 16 in your own project. If any does not occur naturally, cause it: remove the normalization from a migration, artificially delay a PUT, or delete a subscription's unsubscribe.
2. For each one, document in docs/debugging.md: symptom, reproduction procedure, minimal case, failing test, hypotheses (including the discarded ones), root cause and fix.
3. Leave all three regression tests in the suite.
4. Run the complete accessibility review: automated axe on the 7 screens (including the empty and error states) and the 8 manual tests. Write docs/accessibility.md in the format from section 17.3, including the known limitations.
5. Generate realistic data (≥ 500 tasks, ≥ 3,000 history entries) and measure your baseline with the protocol from 09-01 against the production build. Write docs/performance.md with the 9-row table comparing the budget, your result and Nómada Tasks.
6. Run the full suite five times in a row. If any run fails, find and fix the flaky test before considering the milestone closed.

Acceptance criteria for exercise 1 — Suite

Rubric for exercise 1 (27 points)

Threshold: 19/27, with a mandatory ≥ 2 in "Rule coverage" and in "Reliability".

Acceptance criteria for exercise 2 — CI

Acceptance criteria for exercise 3 — Debugging and reports

Overall rubric for milestone H5 (24 points)

Threshold: 17/24. Plus one additional condition that cannot be traded away: the suite has to be green five times in a row. A flaky suite is not finished, however many tests it has.

Self-assessment for milestone H5:

You have turned "it works on my machine" into "it works, and there is a machine that checks it on every push".

You have a testing strategy built on three questions — what must never fail, what changes often, and how much each test costs and is worth — and on a decision rule that resolves almost every case: test at the lowest level that catches the failure you are worried about. You have the pyramid translated into your concrete files, with about 250 tests of which only three are end to end, and with an observation that is a free diagnosis: if you had more view tests than domain tests, your logic would be in the wrong place.

You know how to use coverage without being fooled by it: it says what is not tested, not whether what is tested is well tested. That is why your thresholds are per layer and justified — 95 % in the domain, 100 % in migrations, 65 % in the view — and why the metric that really governs is not the percentage but the rules × three cases table: fifteen rules, forty-five minimum tests, and no gap you can pass without verifying anything.

You know how to test the domain with parameterized tables that read as a specification, with the exact boundaries where the bugs live — 40 and 40.1, not 20 — with the type cases that slip through naive validations — '12' and NaN — checking error.field and not just the error type, and with the three families of edge case everybody forgets: numeric, collection and time, including the week 53 that breaks almost every homegrown ISO-week implementation.

You know how to test the data layer by replacing only the slow, the external and the non-deterministic: a fake fetch that fails on unexpected calls, fake timers with advanceTimersByTimeAsync — and not the synchronous version, which leaves microtasks undrained — a fixed clock, and assertions about the number of calls, which is what distinguishes a real retry test from one that would pass just as well with the retry broken. With the migrations tested against real documents, including the performance test that stops a slow migration from wrecking the LCP, and with the queue tested on what is impossible to verify by hand: that resending uses the same idempotency key.

You know how to test the view the way a person uses it: by role and accessible text, never by CSS class, with the double benefit of surviving layout changes and verifying accessibility for free. And you know how to test the keyboard walkthrough, which almost no project has, covering the three classic focus bugs — not entering, not returning, escaping — which with a native <dialog> pass almost by themselves.

You have three end-to-end journeys chosen with an explicit criterion — the ones that, if broken, would leave the product useless — covering the complete lifecycle with R13 genuinely enforced, the shared state in the URL with the report, and offline resilience with the duplicate check. And you know why not twenty: a disabled end-to-end suite is worth zero, so the right number is the maximum you can keep permanently green.

You have continuous integration complete and commented line by line: concurrency that cancels the stale, an npm cache, npm ci instead of install, artifacts uploaded on failure too — which is exactly when you need them — slow jobs depending on the fast one, and branch protection that turns the recommendation into a guarantee. With Lighthouse CI enforcing your 11-01 budget translated into assertions, three runs because of the noise, error only where you signed up for it, and the 61,440-byte line that stops a charting library getting in one day without anyone noticing.

And you know how to debug your own project with a six-step method whose third step — writing the failing test before fixing — is the one almost everybody skips and the one that gives four benefits at once. You have applied it to three real failures: the migration that corrupted data by matching names with different Unicode normalization, with its three lessons — match by identifier, do not fail silently, and the backup saved the investigation; the race condition where an in-flight refresh overwrote an optimistic update, where reproducing required controlling the timing to turn "one time in three" into "always"; and the memory leak of twenty-one live views retained by subscriptions with no unsubscribe, which cannot be seen but can be measured, and which is prevented forever by a one-millisecond unit test.

You know that automated accessibility tools detect around a third of the problems, and you have both halves: axe over the seven screens — including the empty and error states, which nobody tests and where the most violations are — and the eight manual tests taking fifty minutes, with the screen reader and closed eyes as the one that teaches most. With a report that states its limitations, which is worth more than a Lighthouse 100.

You have your baseline measured against the production build, with realistic data, compared to Nómada Tasks row by row, and you know how to read it: being somewhat heavier with more functionality is correct, being under budget is headroom and not permission, and every out-of-range row points to its Module 9 lesson.

And you know how to treat flaky tests as what they are: real failures that destroy trust in the suite. With the eight causes and their solutions, the protocol of never re-running, and the hygiene rule of five consecutive runs before closing a milestone.

Milestone H5 is closed. Your project works, it is tested, it is measured and it watches itself. It is missing the one thing that turns a repository into a product: that other people can use it. Building for production without leaking a single secret, choosing where to host it, configuring caching, security and HTTPS, deploying continuously with the ability to roll back, and watching over it once it is no longer on your machine, is Deploying the Project.