Erlang basics · Lesson 31 (open contents)
Prove the project is done
Run the acceptance matrix, then finish with a short release checklist.
Run this first
Run it once, change one input, and compare the new result.
%% 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).- The acceptance result is
truewhen all three promises still hold.
Read from the first line down
- Read
lists:all/2: Confirm that every acceptance case passes. - Read
rebar3 do eunit, ct: Run unit and Common Test suites. - Read
$?: In a shell, inspect whether the command exited successfully.
Symbols are not secret signs
lists:all/2Confirm that every acceptance case passes.
rebar3 do eunit, ctRun unit and Common Test suites.
$?In a shell, inspect whether the command exited successfully.
Match each name to its meaning
acceptance matrix
A matrix runs agreed inputs through the public API and compares exact outputs.
regression
A regression is old behavior that breaks after a later change.
release checklist
A short checklist verifies tests, documentation, packaging, and known limits.
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.
Close the answer and try
Add the WARN case to the matrix.
{<<"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
{<<"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.
Remember these three lines
- 1
Finish against the original promises.
- 2
Keep regressions executable.
- 3
Ship with a small repeatable checklist.