Erlang basics · Lesson 31 (open contents)
01 · Open erl02 · Meet common terms03 · Tell two kinds of text apart04 · Bind a variable once05 · Split and filter a list06 · Parse a number safely07 · Choose one path with case08 · Let a function keep going09 · Put code in a module10 · Compare terms and Boolean results11 · Read and update nested maps12 · Build and inspect UTF-8 binaries13 · Let clauses choose the function path14 · Solve a list twice15 · Choose with patterns, guards, and errors16 · Describe a module and one record17 · Put one tested module in Rebar318 · Return success or failure as data19 · Read and write one file safely20 · Build a data pipeline with functions21 · Keep records behind a module boundary22 · Define a module contract23 · Describe the data contract24 · Test small rules and whole flows25 · Shape builds and make 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
ERLANG · PROJECT · LESSON 3135 minutes

Prove the project is done

Run the acceptance matrix, then finish with a short release checklist.

01 · Start with the whole example

Run this first

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

Erlang
%% Run each promise through the public parser
Cases = [
  {<<"INFO ready">>, {ok, {info, <<"ready">>}}},
  {<<>>, skip},
  {<<"BROKEN">>, {error, invalid_line}}
],
lists:all(fun({Input, Expected}) -> cleaner:parse_line(Input) =:= Expected end, Cases).
Check the result first
  • The acceptance result is true when all three promises still hold.
02 · Take the code apart

Read from the first line down

  1. Read lists:all/2: Confirm that every acceptance case passes.
  2. Read rebar3 do eunit, ct: Run unit and Common Test suites.
  3. Read $?: In a shell, inspect whether the command exited successfully.
03 · Meet the new symbols

Symbols are not secret signs

lists:all/2

Confirm that every acceptance case passes.

rebar3 do eunit, ct

Run unit and Common Test suites.

$?

In a shell, inspect whether the command exited successfully.

04 · Ideas inside the code

Match each name to its meaning

01

acceptance matrix

A matrix runs agreed inputs through the public API and compares exact outputs.

02

regression

A regression is old behavior that breaks after a later change.

03

release checklist

A short checklist verifies tests, documentation, packaging, and known limits.

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.

A matrix runs agreed inputs through the public API and compares exact outputs.

A regression is old behavior that breaks after a later change.

06 · Change it yourself

Close the answer and try

Add the WARN case to the matrix.

Practice starting point
{<<"WARN hot">>, ____}

Target result: Use {ok,{warn,<<"hot">>}}.

Stuck? Read one hint

Copy the shape from the brief.

After you run it, see one answer
One answer
{<<"WARN hot">>, {ok, {warn, <<"hot">>}}}
Think about it: Is a green acceptance matrix enough by itself?

No. Also run the suites, check docs, build the command, and record known limits.

Take with you

Remember these three lines

  1. 1

    Finish against the original promises.

  2. 2

    Keep regressions executable.

  3. 3

    Ship with a small repeatable checklist.

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