Elixir basics · Lesson 29 (open contents)
01 · Let the code speak02 · Meet six kinds of values03 · Put values together04 · Build a new list05 · Make the shapes match06 · Choose with case07 · Parse a number safely08 · Unpack &1 and the pipe09 · Put code in a project10 · Ask precise true-or-false questions11 · Read and update nested data12 · Count visible text and bytes13 · Let function clauses choose14 · Solve a list twice15 · Choose the smallest clear control form16 · Give domain data a shape17 · Put one tested module in Mix18 · Make success and failure predictable19 · Read and write one real file20 · Take only the data you need21 · Give different data one shared action22 · Write a callback contract23 · Write down the data contract24 · Test behavior and boundaries25 · Turn a project into a command26 · Write the project promise27 · Parse one real line28 · Keep the public API small29 · Make the promise executable30 · Package the edge and leave clues31 · Prove the project is done
ELIXIR · PROJECT · LESSON 2935 minutes

Make the promise executable

Add docs, specs, examples, and boundary tests to the project API.

01 · Start with the whole example

Run this first

Run it once, change one input, and compare the new result.

Elixir
# test/cleaner_test.exs
defmodule CleanerTest do
  use ExUnit.Case, async: true

  describe "parse_line/1" do
    test "accepts a known level" do
      assert Cleaner.parse_line("INFO ready") == {:ok, {:info, "ready"}}
    end

    test "rejects a malformed line" do
      assert Cleaner.parse_line("BROKEN") == {:error, :invalid_line}
    end
  end
end
Check the result first
  • mix test should report two passing contract tests.
02 · Take the code apart

Read from the first line down

  1. Read @doc: Explain behavior and include a small example.
  2. Read @spec: State accepted and returned term shapes.
  3. Read assert / refute: Check positive and negative behavior.
03 · Meet the new symbols

Symbols are not secret signs

@doc

Explain behavior and include a small example.

@spec

State accepted and returned term shapes.

assert / refute

Check positive and negative behavior.

04 · Ideas inside the code

Match each name to its meaning

01

public contract

Docs, specs, and tests describe the same externally visible behavior.

02

doctest

A doctest turns a short documented IEx example into a regression check.

03

fixture

A small fixed input makes edge cases repeatable.

05 · Make the idea clear

Why these forms are useful

Run the example first. Predict one result, then change one input and run it again.

Docs, specs, and tests describe the same externally visible behavior.

A doctest turns a short documented IEx example into a regression check.

06 · Change it yourself

Close the answer and try

Add a test for an empty line.

Practice starting point
test "skips empty input" do
  assert Cleaner.parse_line("") == ____
end

Target result: Expect :skip.

Stuck? Read one hint

Use the brief's exact result.

After you run it, see one answer
One answer
test "skips empty input" do
  assert Cleaner.parse_line("") == :skip
end
Think about it: Which artifact wins when docs and tests disagree?

Fix the disagreement against the agreed acceptance examples; all contract artifacts should say the same thing.

Take with you

Remember these three lines

  1. 1

    Keep docs, specs, and tests aligned.

  2. 2

    Test failures as carefully as success.

  3. 3

    Use tiny fixtures that show one rule.

Lesson completeRun the code once, then mark this lesson as done.