Module eqc_ct

This module embeds a file with QuickCheck properties into a test SUITE for the common-test framework.

Copyright © Quviq AB, 2007-2017

Version: 1.42.1

Description

This module embeds a file with QuickCheck properties into a test SUITE for the common-test framework.

Each property exported from a BEAM file corresponds to a test in common test. However, properties with arguments cannot automatically be initialized with meaningful values. Therefore, only the properties of arity zero are transformed to test cases. This means that whenever you have a property of arity larger than zero in your _eqc file, you should provide another property of arity zero that embeds that property. For example, we have a property to check encryption and decryption of messages. For encryption we need a key and we need the same key to decrypt. However, the key must be a prime number of 64 bits. Since we want to check the encryption on some real keys, we created the following property:
 prop_communicate(Key) ->
    ?FORALL(Msg,message(),
            decode(Key,encode(Key,Msg)) == Msg).
Now for automatic testing, we like to add an extra property that chooses a specific configuration, or a number of them, and test the above property in that configuration.
 prop_communicate() ->
    prop_communicate(<<41:64>>).
Or, alternatively, with a bit more randomness:
 prop_communicate() ->
    ?FORALL(Key,key(),
            prop_communicate(Key).

where we make a key generator that either picks a key from a given list of keys or (expensive) creates a valid key.

Thus, given a module, all exported functions of arity zero starting with prop_ are used to create test cases from, by calling quickcheck on those properties.

We start from a BEAM file, since we only need exported properties. However, it is very useful in common test to see the source of the property as well. Therefore, if the source of the property is included in the BEAM file (via compile flag debug_info), then we add it as comments to the SUITE. The choice to add it as comments instead of source code is motivated by stressing that the code in the module containing the properties is the final form of specification, and in addition by the technical problem of preventing name conflicts.

Function Index

compile/1Equivalent to compile(Module, []).
compile/2Given a compiled module, a common test SUITE is generated as BEAM file that calls all properties with zero arity in that module as test cases.
compile_mods/1Given a list of module names, the function compile/1 is called on each of these.
module/1Given a compiled module, a common test SUITE is generated as syntax tree in which all properties with zero arity in that module are called as test cases.

Function Details

compile/1

compile(Module::atom()) -> {ok, ModuleName::atom()} | error

Equivalent to compile(Module, []).

compile/2

compile(Module::atom(), Options::[Option::option()]) -> {ok, ModuleName::atom()} | error

Given a compiled module, a common test SUITE is generated as BEAM file that calls all properties with zero arity in that module as test cases. Properties should all start with prop_ in order to be recognized as properties and are translated to check_prop_... as test case. The options one can provide are the same options as those for compile:file/2. In addition one may provide the option {properties,[Names::atom()]} in which Names represent the function names that should be considered as properties. This is only useful if you diverted from the convention to call properties prop_....

With the compiler option {outdir,Dir} one can specify in which directory the generated BEAM file should be created.

If Module contains any of the common test callbacks init_per_suite/1, end_per_suite/1, init_per_testcase/2, end_per_testcase/2 they will be called by the corresponding callbacks in the generated suite. Note that init_per_group and end_per_group are not supported.

compile_mods/1

compile_mods(Modules::[Module::atom()]) -> {ok, [ModuleName::atom()]} | error

Given a list of module names, the function compile/1 is called on each of these. This is in particular useful if run from the command line with the erl -s option.

module/1

module(Module::atom()) -> syntaxTree()

Given a compiled module, a common test SUITE is generated as syntax tree in which all properties with zero arity in that module are called as test cases. Properties should all start with prop_ in order to be recognized as properties and are translated to check_prop_... as test case.

One can use erl_prettypr:format(module(Module)) to get a printed output of the source code.


Generated by EDoc, Sep 18 2017, 16:17:37.