我已阅读关于EUnit的documentation,但我仍然不知道测试生成器的用途是什么。
我还阅读了一个很好的教程here,但仍然没有运气(有点过于先进)。
我有点理解测试生成器函数返回一组测试,然后由EUnit执行。 (是吗?)
不幸的是,我现在唯一自信的是我可以写一个这样的测试:
myfun_test() ->
assertEqual(myresult,mymod:myfun()).
问题是: EUnit中需要哪些测试生成器以及它们与简单测试对象的关系是什么?
P.S。我知道有一个奇妙的世界(example)单元测试是在各种自动化工具和概念的帮助下完成的,但我不知道如何输入它。
答案 0 :(得分:2)
我想如果你试图为你的项目编写一些单元测试,你会发现测试生成器在实践中的价值。
如果使用测试生成器,则不需要花时间创建许多不同的测试函数名称,并且创建测试生成器的代码比标准函数短。
例如,以下代码来自测试生成器的gproc
开源项目,它使用测试生成器作为参考,该文件可以在github.
reg_test_() ->
{setup,
fun() ->
application:start(gproc),
application:start(mnesia)
end,
fun(_) ->
application:stop(gproc),
application:stop(mnesia)
end,
[
{spawn, ?_test(?debugVal(t_simple_reg()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_simple_counter()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_simple_aggr_counter()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_update_counters()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_simple_prop()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_await()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_await_self()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_await_crash()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_simple_mreg()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_gproc_crash()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_cancel_wait_and_register()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_give_away_to_pid()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_give_away_to_self()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_give_away_badarg()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_give_away_to_unknown()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_give_away_and_back()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_select()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_select_count()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_qlc()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_get_env()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_get_set_env()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_set_env()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_get_env_inherit()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_monitor()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_monitor_give_away()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_subscribe()))}
, ?_test(t_is_clean())
, {spawn, ?_test(?debugVal(t_gproc_info()))}
, ?_test(t_is_clean())
]}.
答案 1 :(得分:1)
从您在问题中链接的页面中读取:
简单测试功能的缺点是必须单独编写 每个测试用例的函数(具有单独的名称)。更紧凑的方式 编写测试(更灵活,我们将会看到),是 编写返回测试的函数,而不是测试。
名称以... test ()结尾的函数(注意最终版本 下划线)被EUnit认可为测试生成器功能。测试 生成器返回要执行的一组测试的表示 EUnit。
考虑测试生成器分组测试的可能性。除了拥有更紧凑的代码之外,您还可以为测试提供高级功能。例如,一组状态用于您的测试集,一个初始化函数,依此类推。
如果您的应用程序需要的只是一组断言,那么您可能不需要测试集。你甚至可以避免使用EUnit作为一个整体。 Erlang中的模式匹配(=)运算符本身就是一个出色的测试运算符。比较:
assertEqual(myresult,mymod:myfun()).
使用:
myresult = mymod:myfun()