exploreSignatures: Explore Signatures
In neonira/wyz.code.metaTesting: Wizardry Code Meta Testing

Description Usage Arguments Details Value Author(s) See Also Examples

Test an offensive programming wrapper function, applying various argument signatures.

1
2
3

exploreSignatures(fun_f_1,
                  argumentsTypeRestrictions_l = list(),
                  signaturesRestrictions_l = list())

`fun_f_1`	a single R function. Must be an offensive programming wrapper function. See `opwf`.
`argumentsTypeRestrictions_l`	a named `list`. Each name must match a function argument name. Each content must be a vector of strings, each of them matching a `retrieveDataFactory()$getKnownSuffixes()` known suffix.
`signaturesRestrictions_l`	an unnamed `list` of single strings, each of them matching one of `computeArgumentsCombination(fun_f_1)$signature`.

This function offers a really convenient way to test your own functions, without the burden of building the execution context, that is much trickier than one can imagine at first glance.

Moreover it provides argument signature analysis, which is not provided by testFunction.

Arguments restriction parameter argumentsTypeRestrictions_l allows to restrict on demand, value types exploration. It is very useful and convenient to reduce the exploration tree, and to shorten execution time.

By default, a total of 768 tests will run for a single function, when no signaturesRestrictions_l is set. This may requires some time to achieve.

When working interactively, a good practice is to use computeArgumentsCombination prior to use function computeArgumentsCombination, as it will provide complexity information about the function you wish to test. The number of signature is a good metric of function call complexity. Know that each of them will be tested, and data generation has to be achieved for each parameter according to global or restricted scheme, depending on your argumentsTypeRestrictions_l inputs.

A list with names info, success, failure, each of them being a list.

The info sub-list holds execution results. It holds following entries

raw is a list, providing capture of execution context, data and results.
good is a list, providing same information as raw, filtered to retain only tests that do not generate any error.
bad is a list, providing same information as raw, filtered to retain only tests that do generate error.

The success sub-list holds analysis results for tests which do not generate errors. It holds following entries

code is a data.table, providing used call code and results.
table is a data.table, providing used argument signatures and execution context information.
synthesis is a list, providing synthesis information. Much easier to read, than table entry.

The failure subsist holds analysis results for tests which do generate errors. It holds following entries

table is a data.table, providing encountered error messages and execution context information
synthesis is a list, providing synthesis information. Much easier to read, than table entry.

Fabien Gelineau <neonira@gmail.com>

Maintainer: Fabien Gelineau <neonira@gmail.com>

Refer to testFunction and to generateData.

# typical use case
op_sum <- opwf(sum, c('...', 'removeNA_b_1'))

rv_sum <- exploreSignatures(op_sum, list(... = c('im', 'r', 'cm')))

# which are the errors of exploration and in what context do they occur?
print(rv_sum$failure$synthesis)

# which are the good behaviors of exploration and in what context do they occur?
print(rv_sum$success$synthesis)

# Restrict signatures to use for exploration testing on op_sum
# Consider only two cases: no argument and ellipsis1_, ellispsis2_
cac_sum <- computeArgumentsCombination(op_sum)
rv_sum_f <- exploreSignatures(op_sum, list(... = c('im', 'r', 'cm')),
                              cac_sum$signatures[c(1, 5)])