[erlang-questions] PropEr testing of a fixed set of atoms

[Samuel]

Hi,

I don't know what is your definition of unit testing, but to me it is
not about the tool you use but what you are actually testing. From the
example you posted I understand you are writing tests to verify the
API of a module somewhat in isolation, which falls into what I
understand is unit testing.

Regardless of your tool selection, what you want to do falls outside
the model of quickchecking using generators, as you don't want to
generate random data. You simply want to evaluate a static expression
and verify that it returns true (and doesn't crash in the match with
true). I understand the ?FORALL notation seems natural when you want
to test all the values contained in one type, but that is not what
?FORALL does, it tests a fixed number of samples, 100 by default, not
all. For the same reason, you are not using the same technique either.

You can, of course, find ways of using proper for this for the sake of
running all your tests in proper if that is valuable for you. I would
advise to use the right tool for the right job though.

Anyway, given that proper already parses your types, it wouldn't be
unreasonable for it to provide an api to use that information, so that
you could get the DictTypes list without duplicating the types in your
code. I don't know if the proper guys are willing to invest on that or
accept a contribution that does it.

 You could also read the type information yourself, as proper does,
from the module abstract code.

On 3 June 2014 17:54, Jay Nelson <jay@REDACTED> wrote:
>
> On Jun 3, 2014, at 4:29 AM, Samuel <samuelrivas@REDACTED> wrote:
>
>> Hi,
>>
>> Why are you using proper at all for this task? If you want exhaustive
>> testing, just write a tests that goes over all the alternatives. Using
>> eunit:
>>
>> new_dict_test_() ->
>>    DictTypes = [vbisect, dict, orddict],
>>    [ ?_assert(valid_empty_dict(T, my_dict_module:new(T))) || T <- DictTypes].
>>
>
> Several reasons:
>
> 1) I believe unit testing is too brittle and attached to the code written
> 2) I prefer to use a single technique where comprehensive
> 3) I want to avoid repeating the list of valid datatype atoms (which occur in -type)
> 4) I am using PropEr for other property tests as my main tool
> 5) PropEr already knows about my type declarations
>
>
> Because of my experience on several projects with #1 I’ve stopped
> using xUnit tools. Several years ago I adopted common_test over
> eunit. Now I am looking to improve my coverage in a more general
> fashion and I run PropEr from within common_test with cover to aid
> in detecting code that my property tests overlook. I also believe thinking
> in property-based testable terms leads to a better code architecture
> over unit-testing specific functions.
>
> PropEr has built-in generators that already enumerate the datatypes,
> but select randomly from them when generating test cases. In the case
> of a fixed, limited set of enumerables, it should be an obvious property
> to test them all. I just thought I was missing something in the
> documentation that allowed controlling the randomness without
> jumping through hoops to create filters and a dictionary of already
> seen values.
>
> jay
>



-- 
Samuel