Unit Project: Tested Modular App

Unit Project: Tested Modular App | JavaScript Course | SovranCode

COMPLETE LESSON · ABOUT 65 MIN OF ACTIVE PRACTICE

Learn Unit Project: Tested Modular App step by step

Follow the lesson in order: understand the model, trace worked examples, run a controlled experiment, debug a faulty assumption, build independently, and verify your reasoning.

LESSON MAP

What you will understand and apply

Draw dependency direction before writing modules
Test domain rules without DOM or network
Run a documented keyboard and failure-state review
Build a study planner with domain modules, storage and DOM adapters, import/export, tests, accessibility review, and a release checklist.

DEEP EXPLANATION

Build the complete mental model

Build the mental model

Start with a module diagram. Domain functions validate and transform study-plan records without browser globals. A storage adapter serializes a versioned snapshot. A DOM adapter renders and translates events into domain commands. The application entry point composes those pieces. Dependencies should point inward toward stable rules rather than letting domain code import the page. Before writing more syntax, name the values involved in Unit Project: Tested Modular App, who creates them, and which result or effect the program promises. Trace the smallest example by hand and identify any browser or runtime API separately from the language feature. A useful mental model should predict a changed input, not merely describe the demonstration after it runs.

Use the API deliberately

Write a test matrix before implementation. Unit tests cover validation, duration totals, immutable completion updates, and empty plans. Adapter tests use controlled storage and DOM fixtures. One integration journey creates, completes, reloads, exports, and imports a plan. Tests assert public results instead of private calls so refactoring remains possible. During implementation, keep the module rule in a focused function or event boundary with explicit inputs. Choose names that reveal the domain, keep calculation separate from document, console, storage, or network effects, and prefer the narrowest API that expresses the problem. Compare this design with one reasonable alternative and explain why the selected construct makes ownership or control flow clearer.

Handle boundaries and tradeoffs

Release evidence includes passing automated checks, manual keyboard navigation, visible focus, zoom and narrow-layout review, invalid-import recovery, corrupted-storage recovery, and a security pass for untrusted text. Document tradeoffs and remaining limits. The project is complete only when another learner can run it from the README and reproduce the evidence. Verification for Unit Project: Tested Modular App must cover an ordinary case, an empty or missing case, invalid input, and the most important threshold. Predict each result before running it, then locate the first value that violates the contract when reality differs. Record the corrected case as a repeatable check and explain which product behavior should occur instead of allowing undefined, NaN, stale data, or silent failure to spread.

WORKED EXAMPLES

Read the decision before the syntax

Example 1: Project foundation

Trace this Unit Project: Tested Modular App example from validated input to returned value or visible effect before editing it.

function createStudyPlan(items) {
  if (!Array.isArray(items)) throw new TypeError("Items must be an array");
  const normalized = items.map(item => {
    if (!item || typeof item.title !== "string" || !Number.isInteger(item.minutes)) throw new TypeError("Invalid item");
    return { id: String(item.id), title: item.title.trim(), minutes: item.minutes, done: item.done === true };
  });
  return {
    items: normalized,
    totalMinutes: normalized.reduce((sum, item) => sum + item.minutes, 0),
  };
}
console.log(createStudyPlan([{ id: 1, title: " Modules ", minutes: 40 }]));

Example 2: Second worked example

This variation changes the shape of the problem so you can compare the underlying module contract instead of copying one solution.

export function completeItem(plan, id) {
  let found = false;
  const items = plan.items.map(item => {
    if (item.id !== id) return item;
    found = true;
    return { ...item, done: true };
  });
  if (!found) throw new RangeError("Study item not found");
  return { ...plan, items };
}
const original = { items: [{ id: "js", done: false }] };
console.log(completeItem(original, "js"));

How to trace this lesson

Write down the exact inputs used by Unit Project: Tested Modular App.
Predict each returned value and observable effect before running the example.
Mark the first boundary where invalid or missing data could enter.
Verify the ordinary, empty, invalid, and threshold cases independently.

Common mistakes and corrections

Putting storage, requests, calculations, and DOM updates in one exported function makes every change require an expensive integration setup.: Make the module rule explicit and cover it with a focused example.
Changing several parts of the example before explaining the original result.: Make one change at a time and compare it with a written prediction.
Testing only the demonstration's happy path.: Add missing, invalid, empty, and boundary inputs that exercise the stated contract.

PRACTICE LADDER

Move from recognition to independent work

1
Draw dependency direction before writing modules
2
Test domain rules without DOM or network
3
Run a documented keyboard and failure-state review
4
Build a study planner with domain modules, storage and DOM adapters, import/export, tests, accessibility review, and a release checklist.

Complete these in order. The final step should work without copying the lesson example; use the runner and lab below to test it.

Core rule

Applied boundary

RUNNABLE EXAMPLE

Change one assumption at a time

Predict the output, run the example, then change one input and one boundary in the Unit Project: Tested Modular App example. Explain every changed result before continuing.

function createStudyPlan(items) {
  if (!Array.isArray(items)) throw new TypeError("Items must be an array");
  const normalized = items.map(item => {
    if (!item || typeof item.title !== "string" || !Number.isInteger(item.minutes)) throw new TypeError("Invalid item");
    return { id: String(item.id), title: item.title.trim(), minutes: item.minutes, done: item.done === true };
  });
  return {
    items: normalized,
    totalMinutes: normalized.reduce((sum, item) => sum + item.minutes, 0),
  };
}
console.log(createStudyPlan([{ id: 1, title: " Modules ", minutes: 40 }]));

function createStudyPlan(items) {
  if (!Array.isArray(items)) throw new TypeError("Items must be an array");
  const normalized = items.map(item => {
    if (!item || typeof item.title !== "string" || !Number.isInteger(item.minutes)) throw new TypeError("Invalid item");
    return { id: String(item.id), title: item.title.trim(), minutes: item.minutes, done: item.done === true };
  });
  return {
    items: normalized,
    totalMinutes: normalized.reduce((sum, item) => sum + item.minutes, 0),
  };
}
console.log(createStudyPlan([{ id: 1, title: " Modules ", minutes: 40 }]));

Press Run to execute your code.

DEBUGGING CHALLENGE

Locate the first incorrect value

Predict the failure and write your repair before revealing the explanation.

export async function total() {
  const response = await fetch("/api/items");
  document.body.textContent = String((await response.json()).reduce((sum, item) => sum + item.minutes, 0));
}

Reveal repair and explanation

export function totalMinutes(items) {
  return items.reduce((sum, item) => sum + item.minutes, 0);
}

The repaired domain function has explicit input and output; network and rendering belong in adapters that can be tested separately.

INDEPENDENT LAB

Build without copying the example

Build a study planner with domain modules, storage and DOM adapters, import/export, tests, accessibility review, and a release checklist.

// Define small functions before composing the complete solution.
// Build a study planner with domain modules, storage and DOM adapters, import/export, tests, accessibility review, and a release checklist.

// Define small functions before composing the complete solution.
// Build a study planner with domain modules, storage and DOM adapters, import/export, tests, accessibility review, and a release checklist.

Press Run to execute your code.

Self-review checklist Draw dependency direction before writing modules Test domain rules without DOM or network Run a documented keyboard and failure-state reviewWhat did you predict, observe, and change?

KNOWLEDGE CHECK

Explain the rule, not only the syntax

1. Which module should know about both the DOM adapter and domain functions? The application composition entry point Every domain calculation The JSON data file

2. Which evidence best demonstrates mastery of Unit Project: Tested Modular App? A prediction, boundary tests, and an explained result A copied snippet with no changes One successful happy-path run

Loading saved work…

Code and answers save automatically. Guest work stays on this device; signed-in work syncs to your account. The runner is isolated, blocks network access, and stops long-running console programs.

1. JavaScript Foundations

2. Functions and Collections

3. Objects and Structured Data

4. Browser Interfaces

5. Async and Reliable Applications

6. Application Engineering