小测试与整段路

用 EUnit 守住纯函数，用 Common Test 检查较长场景。

01 · 先看完整例子

把折扣边界写进 EUnit

生成器返回多条测试，任一失败会指出对应断言。

Erlang

-include_lib("eunit/include/eunit.hrl").

discount_test_() ->
  [
    %% 满 10 件打九折
    ?_assertEqual(90.0, discount:price(100, 10)),

    %% 9 件仍按原价
    ?_assertEqual(100, discount:price(100, 9))
  ].

先对照结果

实现符合规则时，两条 EUnit 测试通过。

02 · 回头拆代码

从第一行往下读

两个输入落在规则边界两侧。
EUnit 不需要外部资源，适合并保持快速。
若以后测试文件服务或多进程协作，再考虑 Common Test fixture。

03 · 认清新符号

符号不是暗号

?assertEqual

EUnit 的相等断言。

_test_

EUnit 测试生成器命名后缀。

rebar3 ct

运行 Common Test suite。

04 · 代码里的概念

把名字和意思对上

test fixture

测试运行前准备、运行后清理的资源或数据。

test suite

Common Test 中按场景组织的一组测试用例。

05 · 再说清楚

这些写法为什么有用

EUnit 适合一个函数、一个模块的短测试。Common Test 用 suite 组织更长场景，常见于多个组件或真实资源。

先用最轻工具。两行能讲清的纯函数测试，不必搭一整套 suite。

正常、边界、错误输入都要考虑。测试名或生成器结构应让失败位置清楚。

06 · 自己改一次

合上答案，动手

增加数量为 0 的边界测试。

练习起点

?_assertEqual(____, discount:price(80, ____))

目标结果： 期待 discount:price(80,0) 返回 80。

卡住了，再看提示

两个空分别是 80 和 0。

运行过以后，再看一种答案

一种答案

%% 零也是值得保存的边界
?_assertEqual(80, discount:price(80, 0))

想一想：所有 Erlang 测试都应该使用 Common Test 吗？

不应该。纯函数与小模块先用 EUnit；需要 suite 生命周期和较长集成场景时再用 Common Test。

带走

记住三句

1
测试工具按场景大小选择。
2
EUnit 适合快速单元测试。
3
Common Test 适合带 fixture 的长场景。

本课结束代码也跑过一次，就把这一课收好。