Modules, Testing, and Application Structure

COMPLETE LESSON · ABOUT 28 MIN OF ACTIVE PRACTICE

Learn Modules, Testing, and Application Structure 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

Design small module interfaces and dependency direction.
Separate domain rules from DOM, storage, and network adapters.
Choose unit, integration, and end-to-end tests by risk.
Test observable behavior, boundaries, and failure contracts.

DEEP EXPLANATION

Build the complete mental model

A module should expose a narrow reason to change

Named exports form the public contract; imports make dependencies visible. Domain modules should calculate and validate without reaching into the DOM or network. Adapters translate browser, storage, and HTTP details into domain values. Direct dependencies inward toward stable rules so tests can exercise them without reconstructing the whole application. Avoid circular imports and generic utility files that collect unrelated behavior.

Tests operate at different boundaries

Unit tests give fast feedback for pure rules and boundaries. Integration tests prove real modules and adapters cooperate. End-to-end tests cover a small number of critical user journeys through the running product. More end-to-end tests are not automatically better: failures are slower to diagnose and setup is larger. Place most detailed cases at the narrowest boundary that can prove the behavior.

Good tests protect contracts, not implementation trivia

Arrange meaningful input, act through the public interface, and assert observable output or effect. Include empty, boundary, invalid, and representative valid cases. Control clocks, randomness, and external services through injected dependencies. A test must fail when the contract breaks; assertions that merely repeat the implementation create false confidence and obstruct safe refactoring.

WORKED EXAMPLES

Read the decision before the syntax

Example 1: Inject the external dependency

The domain-facing loader can be tested with a controlled fetcher instead of the real network.

export async function loadCourse(fetcher, id) {
  const response = await fetcher("/api/courses/" + encodeURIComponent(id));
  if (!response.ok) throw new Error("Course unavailable");
  const data = await response.json();
  if (typeof data?.title !== "string") throw new Error("Invalid course");
  return { id, title: data.title };
}

Example 2: Test the public behavior

The assertion describes the money contract and does not depend on the internal loop choice.

function assertEqual(actual, expected, label) {
  if (!Object.is(actual, expected)) throw new Error(label + ": expected " + expected + ", received " + actual);
}

assertEqual(total([]), 0, "empty total");
assertEqual(total([{ priceCents: 1250, quantity: 2 }]), 2500, "line total");

How to trace this lesson

Draw modules as domain rules, adapters, and interface code.
List each public export and the contract it promises.
For every risk, choose the narrowest test boundary that proves it.
Run a deliberate mutation to confirm the test fails for the intended reason.

Common mistakes and corrections

Combining fetch, calculation, storage, and rendering in one export.: Separate stable rules from host adapters and orchestration.
Mocking every private call.: Assert public results and inject only true external boundaries.
Writing only happy-path tests.: Cover empty, invalid, boundary, and failure behavior explicitly.

PRACTICE LADDER

Move from recognition to independent work

1
Split a mixed function into domain, adapter, and UI modules.
2
Define the smallest useful export surface.
3
Write a test matrix before implementing a cart total.
4
Add controlled integration tests for success, invalid data, and HTTP failure.

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

Modules make dependency direction visible

Named exports form a small public interface, while imports declare what another file depends on. Keep domain calculations separate from browser and network adapters so the core logic can run in more than one environment. Avoid a general utilities file that becomes an unowned collection of unrelated behavior.

Test behavior at useful boundaries

A focused unit test documents pure rules quickly. Integration tests prove that real modules, storage, or requests cooperate. Assert observable results rather than private implementation steps, and include boundaries and invalid input. A test that can never fail for the right reason provides false confidence.

RUNNABLE EXAMPLE

Change one assumption at a time

Add an empty-order assertion and an invalid-quantity case. Decide whether validation belongs inside total or at a separate trusted boundary.

function total(items) {
  return items.reduce((sum, item) => sum + item.cents * item.quantity, 0);
}
const actual = total([{ cents: 1250, quantity: 2 }]);
console.assert(actual === 2500, 'expected 2500');
console.log({ actual });

function total(items) {
  return items.reduce((sum, item) => sum + item.cents * item.quantity, 0);
}
const actual = total([{ cents: 1250, quantity: 2 }]);
console.assert(actual === 2500, 'expected 2500');
console.log({ actual });

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 const taxRate = 0.2;
export function total(items) { /* also fetches and renders */ }

Reveal repair and explanation

export function total(items) {
  return items.reduce((sum, item) => sum + item.cents * item.quantity, 0);
}

The repaired module exposes one focused calculation rather than mixing network, rendering, and business rules in the same dependency.

INDEPENDENT LAB

Build without copying the example

Design a price module with a narrow export and tests for valid, empty, and invalid collections.

function total(items) {
  // Implement the domain rule without browser globals.
}

function assertEqual(actual, expected, label) {
  console.assert(Object.is(actual, expected), label);
}

function total(items) {
  // Implement the domain rule without browser globals.
}

function assertEqual(actual, expected, label) {
  console.assert(Object.is(actual, expected), label);
}

Press Run to execute your code.

Self-review checklist The domain function has no DOM or network dependency. Tests describe results and boundary behavior. Money remains integer minor units throughout the calculation.What did you predict, observe, and change?

KNOWLEDGE CHECK

Explain the rule, not only the syntax

1. What does an export define? A module's public interface A browser cookie A CSS cascade layer

2. What should a behavior-focused test assert? Observable results Private line-by-line implementation That no code ever changes

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.

Modules, Testing, and Application Structure | JavaScript Course | SovranCode

1. JavaScript Foundations

2. Functions and Collections

3. Objects and Structured Data

4. Browser Interfaces

5. Async and Reliable Applications

6. Application Engineering