lfex / ltest

A Testing Framework for LFE (successor to lfeunit)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Auto-export tests like vanilla EUnit does

yurrriq opened this issue · comments

Consider (extend-module (export ...) ...).

extend-module is there to allow you to generate module attributes inside the module. Everything is allowed except for the module name.

I'm a little confused by this one :-)

What's the problem (or use case) this ticket is trying to address?

Here are some questions that may help with being more specific so that I'm not so lost :-)

  • What problem or inconvenience was encountered that inspired this ticket? (a sincere question ... I'm not sure what you guys are talking about, so I'm hoping an example will make it clear to me)
  • What does ltest do (or make the user do) which is cumbersome/awkward/etc.?
  • What in particular does EUnit do to solve that?
  • How is EUnit's auto-export different from LFE's (export all)?

I don't like (export all) for one, because it exposes helper functions. Also, I often write test generators that call other test generators and so forth. With (export all) some tests run 4x.

Scratch that I'm going to answer more directly.


What problem or inconvenience was encountered that inspired this ticket?

(export all) caused my tests to be run multiple times each (see description above).
It's not ideal to have to manually translate, e.g. (deftest something-cool ...), to (export (something_cool_test 0)).

What does ltest do (or make the user do) which is cumbersome/awkward/etc.?

It's more of what it doesn't do, and that is automatically export tests like EUnit does.

What in particular does EUnit do to solve that?

Per the user guide:

-include_lib("eunit/include/eunit.hrl").
%% Causes all functions whose names match ..._test() or ..._test_() to be
%% automatically exported from the module (unless testing is turned off, or the
%% EUNIT_NOAUTO macro is defined)

How is EUnit's auto-export different from LFE's (export all)?

It only exports functions whose names match _test() or _test_() so in our case, either manual (defun some_test () ....) etc, or (deftest ...) (deftestgen ...).

Let me know if my scattered thoughts do or don't make sense. 😄

Great answers -- thanks!

It would not be difficult to fix the deftest and deftestgen macros to also automatically export the function as well. There is an extend-module form which can be used for doing this. In that way we would avoid having an (export all) or by default exporting all functions ending in _test and _test_.

I've done just that in #45. Note that it only exports deftest and deftestgen definitions, unlike the eunit_autoexport parse transform, which looks through all functions.