Specifies the initial state of the finite state machine. As with %%% `proper_statem:initial_state/0', its result should be deterministic. %%%
Specifies what the state data should initially contain. Its result %%% should be deterministic
There should be one instance of this function for each reachable
%%% state `StateName' of the finite state machine. In case `StateName' is a
%%% tuple the function takes a different form, described just below. The
%%% function returns a list of possible transitions ({@type transition()})
%%% from the current state.
%%% At command generation time, the instance of this function with the same
%%% name as the current state's name is called to return the list of possible
%%% transitions. Then, PropEr will randomly choose a transition and,
%%% according to that, generate the next symbolic call to be included in the
%%% command sequence. However, before the call is actually included, a
%%% precondition that might impose constraints on `StateData' is checked.
%%% Note also that PropEr detects transitions that would raise an exception
%%% of class `
There should be one instance of this function for each reachable state %%% `{StateName,Attr1,...,AttrN}' of the finite state machine. The function %%% has similar beaviour to `StateName/1', described above.
This is an optional callback. When it is not defined (or not exported), %%% transitions are chosen with equal probability. When it is defined, it %%% assigns an integer weight to transitions from `From' to `Target' %%% triggered by symbolic call `Call'. In this case, each transition is chosen %%% with probability proportional to the weight assigned.
Similar to `proper_statem:precondition/2'. Specifies the %%% precondition that should hold about `StateData' so that `Call' can be %%% included in the command sequence. In case precondition doesn't hold, a %%% new transition is chosen using the appropriate `StateName/1' generator. %%% It is possible for more than one transitions to be triggered by the same %%% symbolic call and lead to different target states. In this case, at most %%% one of the target states may have a true precondition. Otherwise, PropEr %%% will not be able to detect which transition was chosen and an exception %%% will be raised.
Similar to `proper_statem:postcondition/3'. Specifies the %%% postcondition that should hold about the result `Res' of the evaluation %%% of `Call'.
Similar to `proper_statem:next_state/3'. Specifies how the %%% transition from `FromState' to `Target' triggered by `Call' affects the %%% `StateData'. `Res' refers to the result of `Call' and can be either %%% symbolic or dynamic.
"proper/include/proper.hrl" header file,
%%% all API functions of {@module} are automatically
%%% imported, unless `PROPER_NO_IMPORTS' is defined.
%%%
%%% === The role of commands ===
%%% Testcases generated for testing a stateful system are lists of symbolic API
%%% calls to that system. Symbolic representation has several benefits, which
%%% are listed here in increasing order of importance:
%%% Specifies the symbolic initial state of the state machine. This state %%% will be evaluated at command execution time to produce the actual initial %%% state. The function is not only called at command generation time, but %%% also in order to initialize the state every time the command sequence is %%% run (i.e. during normal execution, while shrinking and when checking a %%% counterexample). For this reason, it should be deterministic and %%% self-contained.
Generates a symbolic call to be included in the command sequence, %%% given the current state `S' of the abstract state machine. However, %%% before the call is actually included, a precondition is checked. This %%% function will be repeatedly called to produce the next call to be %%% included in the test case.
Specifies the precondition that should hold so that `Call' can be %%% included in the command sequence, given the current state `S' of the %%% abstract state machine. In case precondition doesn't hold, a new call is %%% chosen using the `command/1' generator. If preconditions are very strict, %%% it will take a lot of tries for PropEr to randomly choose a valid command. %%% Testing will be stopped in case the `constraint_tries' limit is reached %%% (see the 'Options' section in the {@link proper} module documentation). %%% Preconditions are also important for correct shrinking of failing %%% testcases. When shrinking command sequences, we try to eliminate commands %%% that do not contribute to failure, ensuring that all preconditions still %%% hold. Validating preconditions is necessary because during shrinking we %%% usually attempt to perform a call with the system being in a state %%% different from the state it was when initially running the test.
Specifies the postcondition that should hold about the result `Res' of %%% performing `Call', given the dynamic state `S' of the abstract state %%% machine prior to command execution. This function is called during %%% runtime, this is why the state is dynamic.
Specifies the next state of the abstract state machine, given the %%% current state `S', the symbolic `Call' chosen and its result `Res'. This %%% function is called both at command generation and command execution time %%% in order to update the model state, therefore the state `S' and the %%% result `Res' can be either symbolic or dynamic.
All commands were successfully run and all postconditions were true. %%
There was an error while evaluating the initial state.
A postcondition was false or raised an exception.
A precondition was false or raised an exception.
An exception was raised while running a command.