123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571 |
- [/
- / Copyright (c) 2003 Boost.Test contributors
- /
- / Distributed under the Boost Software License, Version 1.0. (See accompanying
- / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
- /]
- [section:test_case_generation Data-driven test cases]
- [h4 Why data-driven test cases?]
- Some tests are required to be repeated for a series of different input parameters. One way to achieve this is
- manually register a test case for each parameter. You can also invoke a test function with
- all parameters manually from within your test case, like this:
- ``
- void single_test( int i )
- {
- __BOOST_TEST__( /* test assertion */ );
- }
- void combined_test()
- {
- int params[] = { 1, 2, 3, 4, 5 };
- std::for_each( params, params+5, &single_test );
- }
- ``
- The approach above has several drawbacks:
- * the logic for running the tests is inside a test itself: `single_test` in the above example is run from the test
- case `combined_test` while its execution would be better handled by the __UTF__
- * in case of fatal failure for one of the values in `param` array above (say a failure in __BOOST_TEST_REQUIRE__),
- the test `combined_test` is aborted and the next test-case in the test tree is executed.
- * in case of failure, the reporting is not accurate enough: the test should certainly be reran during debugging
- sessions by a human or additional logic for reporting should be implemented in the test itself.
- [h4 Parameter generation, scalability and composition]
- In some circumstance, one would like to run a parametrized test over an /arbitrary large/ set of values. Enumerating the
- parameters by hand is not a solution that scales well, especially when these parameters can be described in another
- function that generates these values. However, this solution has also limitations
- * *Generating functions*: suppose we have a function `func(float f)`, where `f` is any number in [0, 1]. We are not
- interested that much in the exact value, but we would like to test `func`. What about, instead of writing the `f`
- for which `func` will be tested against, we choose randomly `f` in [0, 1]? And also what about instead of having
- only one value for `f`, we run the test on arbitrarily many numbers? We easily understand from this small example
- that tests requiring parameters are more powerful when, instead of writing down constant values in the test, a
- generating function is provided.
- * *Scalability*: suppose we have a test case on `func1`, on which we test `N` values written as constant in the test
- file. What does the test ensure? We have the guaranty that `func1` is working on these `N` values. Yet in this
- setting `N` is necessarily finite and usually small. How would we extend or scale `N` easily? One solution is to
- be able to generate new values, and to be able to define a test on the *class* of possible inputs for `func1` on
- which the function should have a defined behavior. To some extent, `N` constant written down in the test are just
- an excerpt of the possible inputs of `func1`, and working on the class of inputs gives more flexibility and power
- to the test.
- * *Composition*: suppose we already have test cases for two functions `func1` and `func2`, taking as argument the
- types `T1` and `T2` respectively. Now we would like to test a new functions `func3` that takes as argument a type
- `T3` containing `T1` and `T2`, and calling `func1` and `func2` through a known algorithm. An example of such a
- setting would be
- ``
- // Returns the log of x
- // Precondition: x strictly positive.
- double fast_log(double x);
- // Returns 1/(x-1)
- // Precondition: x != 1
- double fast_inv(double x);
- struct dummy {
- unsigned int field1;
- unsigned int field2;
- };
- double func3(dummy value)
- {
- return 0.5 * (exp(fast_log(value.field1))/value.field1 + value.field2/fast_inv(value.field2));
- }
- ``
- In this example,
- * `func3` inherits from the preconditions of `fast_log` and `fast_inv`: it is defined in `(0, +infinity)` and in `[-C, +C] - {1}` for `field1` and `field2` respectively (`C`
- being a constant arbitrarily big).
- * as defined above, `func3` should be close to 1 everywhere on its definition domain.
- * we would like to reuse the properties of `fast_log` and `fast_inv` in the compound function `func3` and assert that `func3` is well defined over an arbitrary large definition domain.
- Having parametrized tests on `func3` hardly tells us about the possible numerical properties or instabilities close to the point `{field1 = 0, field2 = 1}`.
- Indeed, the parametrized test may test for some points around (0,1), but will fail to provide an *asymptotic behavior* of the function close to this point.
- [h4 Data driven tests in the Boost.Test framework]
- The facilities provided by the __UTF__ addressed the issues described above:
- * the notion of *datasets* eases the description of the class of inputs for test cases. The datasets also implement several
- operations that enable their combinations to create new, more complex datasets,
- * two macros, __BOOST_DATA_TEST_CASE__ and __BOOST_DATA_TEST_CASE_F__, respectively without and with fixture support,
- are used for the declaration and registration of a test case over a collection of values (samples),
- * each test case, associated to a unique value, is executed independently from others. These tests are guarded in the same
- way regular test cases are, which makes the execution of the tests over each sample of a dataset isolated, robust,
- repeatable and ease the debugging,
- * several datasets generating functions are provided by the __UTF__
- The remainder of this section covers the notions and feature provided by the __UTF__ about the data-driven test cases, in
- particular:
- # the notion of [link boost_test.tests_organization.test_cases.test_case_generation.datasets *dataset* and *sample*] is introduced
- # [link boost_test.tests_organization.test_cases.test_case_generation.datasets_auto_registration the declaration and registration]
- of the data-driven test cases are explained,
- # the [link boost_test.tests_organization.test_cases.test_case_generation.operations /operations/] on datasets are detailed
- # and finally the built-in [link boost_test.tests_organization.test_cases.test_case_generation.generators dataset generators]
- are introduced.
- [/ ################################################################################################################################## ]
- [section Datasets]
- To define properly datasets, the notion of *sample* should be introduced first. A *sample* is defined as /polymorphic tuple/.
- The size of the tuple will be by definition the *arity* of the sample itself.
- A *dataset* is a /collection of samples/, that
- * is forward iterable,
- * can be queried for its `size` which in turn can be infinite,
- * has an arity which is the arity of the samples it contains.
- Hence the dataset implements the notion of /sequence/.
- The descriptive power of the datasets in __UTF__ comes from
- * the [link boost_test.tests_organization.test_cases.test_case_generation.datasets.dataset_interface interface] for creating a custom datasets, which is quite simple,
- * the [link boost_test.tests_organization.test_cases.test_case_generation.operations operations] they provide for combining different datasets
- * their interface with other type of collections (`stl` containers, `C` arrays)
- * the available built-in [link boost_test.tests_organization.test_cases.test_case_generation.generators /dataset generators/]
- [tip Only "monomorphic" datasets are supported, which means that all samples within a single dataset have the same type and same arity
- [footnote polymorphic datasets will be considered in the future. Their need is mainly driven by the replacement of the
- [link boost_test.tests_organization.test_cases.test_organization_templates typed parametrized test cases] by the dataset-like API.]
- . However, dataset of different sample types may be combined together with zip and cartesian product.
- ]
- As we will see in the next sections, datasets representing collections of different types may be combined together (e.g.. /zip/ or /grid/).
- These operations result in new datasets, in which the samples are of an augmented type.
- [/ ###################################################################### ]
- [section Dataset interface]
- The interface of the /dataset/ should implement the two following functions/fields:
- * `iterator begin()` where /iterator/ is a forward iterator,
- * `boost::unit_test::data::size_t size() const` indicates the size of the dataset. The returned type is a dedicated
- class [classref boost::unit_test::data::size_t size_t] that can indicate an /infinite/ dataset size.
- * an enum called `arity` indicating the arity of the samples returned by the dataset
- Once a dataset class `D` is declared, it should be registered to the framework by specializing the template class
- ``boost::unit_test::data::monomorphic::is_dataset``
- with the condition that ``boost::unit_test::data::monomorphic::is_dataset<D>::value`` evaluates to `true`.
- The following example implements a custom dataset generating a Fibonacci sequence.
- [bt_example dataset_example68..Example of custom dataset..run-fail]
- [endsect]
- [/ ###################################################################### ]
- [section Dataset creation and delayed creation]
- Datasets as defined above are constructed before even the test module starts its execution as global objects. This makes impossible to access,
- from within the dataset generator and during their iteration, elements like `argc` / `argv`, the
- [link boost_test.tests_organization.test_tree.master_test_suite master test suite] (and the preprocessed `argc` / `argv`), or any other object
- that has been instantiated after the `main` of the test module entry.
- To overcome this, a [*delayed] dataset instantiation interface has been introduced. This effectively wraps the dataset inside another one,
- which [*lazyly] instantiates the dataset.
- To instantiate a delayed dataset, the [funcref boost::unit_test::data::monomorphic::make_delayed] function should be used in the
- __BOOST_DATA_TEST_CASE__ call. The following snippet:
- ```
- BOOST_DATA_TEST_CASE(dataset_test_case,
- boost::unit_test::data::make_delayed<custom_dataset>(arg1, ... ), ...)
- {
- }
- ```
- creates a delayed dataset test case with a generator of type `custom_dataset`. The generator is ['lazily] constructed
- with `arg1`, `...`.
- [tip A detailed example of delayed creation is given in the section about [link boost_test.runtime_config.custom_command_line_arguments custom command line]
- arguments.]
- [tip See the class [classref boost::unit_test::data::monomorphic::delayed_dataset `monomorphic::delayed_dataset`] for more details on the
- wrapping object.]
- [endsect]
- [endsect] [/ datasets]
- [/ ################################################################################################################################## ]
- [/ Main code import for this section ]
- [import ../snippet/dataset_1/test_file.cpp]
- [/ ################################################################################################################################## ]
- [section:datasets_auto_registration Declaring and registering test cases with datasets]
- In order to declare and register a data-driven test-case, the macros __BOOST_DATA_TEST_CASE__ or __BOOST_DATA_TEST_CASE_F__
- should be used. Those two forms are equivalent, with the difference that `BOOST_DATA_TEST_CASE_F` supports fixtures.
- Those macros are variadic and can be used in the following forms:
- ``
- __BOOST_DATA_TEST_CASE__(test_case_name, dataset) { /* dataset1 of arity 1 */ }
- BOOST_DATA_TEST_CASE(test_case_name, dataset, var1) { /* datasets of arity 1 */ }
- BOOST_DATA_TEST_CASE(test_case_name, dataset, var1, ..., varN) { /* datasets of arity N */ }
- __BOOST_DATA_TEST_CASE_F__(fixture, test_case_name, dataset) { /* dataset1 of arity 1 with fixture */ }
- BOOST_DATA_TEST_CASE_F(fixture, test_case_name, dataset, var1) { /* dataset1 of arity 1 with fixture */ }
- BOOST_DATA_TEST_CASE_F(fixture, test_case_name, dataset, var1, ..., varN) { /* dataset1 of arity N with fixture */ }
- ``
- The first form of the macro is for datasets of arity 1. The value of the sample being executed by the test body is
- available through the automatic variable `sample` (`xrange` is as its name suggests a range of values):
- [snippet_dataset1_1]
- The second form is also for datasets of arity 1, but instead of the variable `sample`, the current sample is brought into `var1`:
- [snippet_dataset1_2]
- The third form is an extension of the previous form for datasets of arity `N`. The sample being a polymorphic tuple, each
- of the variables `var1`, ..., `varN` corresponds to the index 1, ... `N` of the the sample:
- [snippet_dataset1_3]
- The next three forms of declaration, with `BOOST_DATA_TEST_CASE_F`, are equivalent to the previous ones, with the difference being in the support of
- a fixture that is execute before the test body for each sample. The fixture should follow the expected interface as detailed
- [link boost_test.tests_organization.fixtures.models here].
- The arity of the dataset and the number of variables should be exactly the same, the first form being a short-cut for the
- case of arity 1.
- [tip A compilation-time check is performed on the coherence of the arity of the dataset and the number of variables `var1`... `varN`.
- For compilers *without C++11* support, the maximal supported arity is controlled by the macro
- __BOOST_TEST_DATASET_MAX_ARITY__, that can be overridden /prior/ to including the __UTF__ headers.]
- [caution The macros __BOOST_DATA_TEST_CASE__ and __BOOST_DATA_TEST_CASE_F__ are available only for compilers with support for *variadic macros*.]
- [h4 Samples and test tree]
- It should be emphasized that those macros do not declare a single test case (as __BOOST_AUTO_TEST_CASE__ would do) but declare and
- register as many test cases as there are samples in the dataset given in argument. Each test case runs on exactly *one*
- sample of the dataset.
- More precisely, what
- ``__BOOST_DATA_TEST_CASE__(test_case_name, dataset)``
- does is the following:
- * it registers a *test suite* named "`test_case_name`",
- * it registers as many test cases as they are in "`dataset`", each of which with the name corresponding to the index of the sample
- in the database prefixed by `_` and starting at index `0` ("`_0`", "`_1`", ... "`_(N-1)`" where `N` is the size of the dataset)
- This make it easy to:
- * identify which sample is failing (say "`test_case_name/_3`"),
- * replay the test for one or several samples (or the full dataset) from the command line using the [link boost_test.runtime_config.test_unit_filtering test filtering features] provided by the __UTF__,
- * apply a [link boost_test.tests_organization.decorators.explicit_decorator_declaration decorator] to each individual test cases of the
- dataset, as the decorator would apply to the test suite.
- Exactly as regular test cases, each test case (associated to a specific sample) is executed in /monitored manner/:
- * the test execution are independent: if an error occurs for one sample, the remaining samples execution is not affected,
- * in case of error, the [link boost_test.test_output.test_tools_support_for_logging.contexts context] along with the index of the sample
- within which the error occurred is reported in the [link boost_test.test_output log].
- This context contains the sample names and values for which the test failed, which would ease the debugging.
- [endsect]
- [/ ################################################################################################################################## ]
- [section:operations Operations on dataset]
- As mentioned earlier, one of the major aspects of using the __UTF__ datasets lies in the number of operations provided
- for their combination.
- For that purpose, three operators are provided:
- * joins with `operator+`
- * zips with `operator^` on datasets
- * and grids or Cartesian products with `operator*`
- [tip All these operators are associative, which enables their combination without parenthesis. However, the precedence rule on the
- operators for the language still apply. ]
- [section Joins]
- A ['join], denoted `+`, is an operation on two datasets `dsa` and `dsb` of same arity and compatible types, resulting in the *concatenation* of these two datasets `dsa` and `dsb`
- from the left to the right order of the symbol `+`:
- ``
- dsa = (a_1, a_2, ... a_i)
- dsb = (b_1, b_2, ... b_j)
- dsa + dsb = (a_1, a_2, ... a_i, b_1, b_2, ... b_j)
- ``
- The following properties hold:
- * the resulting dataset is of same arity as the operand datasets,
- * the size of the returned dataset is the sum of the size of the joined datasets,
- * the operation is associative, and it is possible to combine more than two datasets in one expression. The following joins are equivalent for any datasets `dsa`, `dsb` and `dsc`:
- ``
- ( dsa + dsb ) + dsc
- == dsa + ( dsb + dsc )
- == dsa + dsb + dsc
- ``
- [warning In the expression `dsa + dsb`, `dsa` and/or `dsb` can be of infinite size. The resulting dataset will have an infinite size as well. If `dsa` is infinite, the content of
- `dsb` will never be reached. ]
- [bt_example dataset_example62..Example of join on datasets..run]
- [endsect]
- [section Zips]
- A ['zip], denoted `^` , is an operation on two datasets `dsa` and `dsb` of same arity and same size, resulting in a dataset where the `k`-th sample of `dsa` is paired with the corresponding `k`-th sample of `dsb`.
- The resulting dataset samples order follows the left to right order against the symbol `^`.
- ``
- dsa = (a_1, a_2, ... a_i)
- dsb = (b_1, b_2, ... b_i)
- dsa ^ dsb = ( (a_1, b_1), (a_2, b_2) ... (a_i, b_i) )
- ``
- The following properties hold:
- * the arity of the resulting dataset is the sum of the arities of the operand datasets,
- * the size of the resulting dataset is equal to the size of the datasets (since they are supposed to be of the same size),
- exception made for the case the operand datasets size mismatch (see below),
- * the operation is associative, and it is possible to combine more than two datasets in one expression,
- ``
- ( dsa ^ dsb ) ^ dsc
- == dsa ^ ( dsb ^ dsc )
- == dsa ^ dsb ^ dsc
- ``
- A particular handling is performed if `dsa` and `dsb` are of different size. The rule is as follow:
- * if the both zipped datasets have the same size, this is the size of the resulting dataset (this size can then be infinite).
- * otherwise if one of the dataset is of size 1 (singleton) or of infinite size, the resulting size is governed by the other dataset.
- * otherwise an exception is thrown at runtime
- [caution If the /zip/ operation is not supported for your compiler, the macro [macroref BOOST_TEST_NO_ZIP_COMPOSITION_AVAILABLE `BOOST_TEST_NO_ZIP_COMPOSITION_AVAILABLE`]
- will be automatically set by the __UTF__]
- [bt_example dataset_example61..Example of zip on datasets..run]
- [endsect] [/ zip operation on datasets]
- [section Grid (Cartesian products)]
- A ['grid], denoted `*` , is an operation on two any datasets `dsa` and `dsb` resulting in a dataset where each sample of `dsa` is paired with each sample of `dsb`
- exactly once. The resulting dataset samples order follows the left to right order against the symbol `*`. The rightmost dataset samples are iterated first.
- ``
- dsa = (a_1, a_2, ... a_i)
- dsb = (b_1, b_2, ... b_j)
- dsa * dsb = ((a_1, b_1), (a_1, b_2) ... (a_1, b_j), (a_2, b_1), ... (a_2, b_j) ... (a_i, b_1), ... (a_i, b_j))
- ``
- The grid hence is similar to the mathematical notion of Cartesian product [footnote if the sequence is viewed as a set].
- The following properties hold:
- * the arity of the resulting dataset is the sum of the arities of the operand datasets,
- * the size of the resulting dataset is the product of the sizes of the datasets,
- * the operation is associative, and it is possible to combine more than two datasets in one expression,
- * as for /zip/, there is no need the dataset to have the same type of samples.
- [caution If the /grid/ operation is not supported for your compiler, the macro [macroref BOOST_TEST_NO_GRID_COMPOSITION_AVAILABLE `BOOST_TEST_NO_GRID_COMPOSITION_AVAILABLE`]
- will be automatically set by the __UTF__]
- In the following example, the random number generator is the second dataset. Its state is evaluated 6 times (3 times for the first `xrange` - first dimension -
- and twice for the second `xrange` - second dimension - to which it is zipped). Note that the state of the random engine is
- not copied between two successive evaluations of the first dimension.
- [bt_example dataset_example64..Example of Cartesian product..run-fail]
- [endsect]
- [endsect] [/ operations on dataset]
- [/ ################################################################################################################################## ]
- [section:generators Datasets generators]
- Several ['generators] for datasets are implemented in __UTF__:
- * [link boost_test.tests_organization.test_cases.test_case_generation.generators.singletons Singletons]
- * [link boost_test.tests_organization.test_cases.test_case_generation.generators.stl `forward iterable`] containers and
- [link boost_test.tests_organization.test_cases.test_case_generation.generators.c_arrays `C` array] like datasets
- * [link boost_test.tests_organization.test_cases.test_case_generation.generators.ranges ranges] or sequences of values
- * datasets made of [link boost_test.tests_organization.test_cases.test_case_generation.generators.random random numbers] and following a particular distribution
- `stl` and `C-array` generators are merely a dataset view on existing collection, while ranges and random number sequences are
- describing new datasets.
- [/ ################################################################################################################################## ]
- [h4:singletons Singletons]
- A singleton is a dataset containing a unique value. The size and arity of such a dataset is 1. This value can be
- * either consumed once
- * or repeated as many times as needed in a zip operation
- As mentioned in /zip/, when zipped with a distribution of infinite size, the resulting dataset will have
- a size of 1.
- The singleton is constructible through the function [funcref boost::unit_test::data::make].
- [bt_example dataset_example65..Singleton..run]
- [/ ################################################################################################################################## ]
- [h4:c_arrays Datasets from C arrays]
- This type of datasets does not contains the logic for generating the sequence of values, and is used as a wrapper on an existing
- sequence contained in a `C` array. The arity is 1 and the size is the size of the array.
- Such datasets are simply constructed from an overload of the [funcref boost::unit_test::data::make `make`] function.
- [bt_example dataset_example66..Array..run]
- [/ ################################################################################################################################## ]
- [h4:stl Datasets from forward iterable containers]
- As for `C` arrays, this type of datasets does not contain the logic for generating sequence of values, and are used for parsing an existing sequence.
- The arity is 1 and the size is the same as the one of the container.
- [tip C++11 implementation enables the dataset generation from any container which iterator implements the forward iterator concept.
- For C++03, the feature is enabled on most STL containers.]
- [bt_example dataset_example67..Dataset from `std::vector` and `std::map`..run]
- [/ ################################################################################################################################## ]
- [h4:ranges Ranges]
- A range is a dataset that implements a sequence of equally spaced values, defined by a /start/, and /end/ and a /step/.
- It is possible to construct a range using the factory [funcref boost::unit_test::data::xrange], available in the overloads below:
- ``
- #include <boost/test/data/test_case.hpp>
- #include <boost/test/data/monomorphic.hpp>
- auto range1 = data::xrange( (data::step = 0.5, data::end = 3 ) ); // Constructs with named values, starting at 0
- auto range2 = data::xrange( begin, end ); // begin < end required
- auto range5 = data::xrange( begin, end, step ); // begin < end required
- auto range3 = data::xrange( end ); // begin=0, end cannot be <= 0, see above
- auto range4 = data::xrange( end, (data::begin=1) ); // named value after end
- ``
- [tip The named value parameters should be declared inside parenthesis]
- [h5 Parameters]
- The details of the named value parameters is given in the table below.
- [table:id_range_parameter_table Range parameters
- [
- [Name]
- [Default]
- [Description]
- ]
- [
- [`begin`]
- [0]
- [Beginning of the generated sequence. The `begin` value is included in set of values returned
- by the generator.
- ]
- ]
- [
- [`end`]
- [+ infinity]
- [End of the generated sequence. The `end` value is not included in set of values returned
- by the generator. If omitted, the generator has infinite size.
- ]
- ]
- [
- [`step`]
- [1]
- [Number indicating the step between two consecutive samples of the generated range.
- The default type is the same as the input type. This value should not be 0. It should be of the same
- sign as `end-begin`.
- ]
- ]
- ]
- [bt_example dataset_example59..Declaring a test with a range..run-fail]
- [/ ################################################################################################################################## ]
- [h4:random Random value dataset]
- This type of dataset generates a sequence of random numbers following a given /distribution/. The /seed/ and the /engine/ may also be
- specified.
- [caution The random value generator is available only for C++11 capable compilers. If this feature is not supported for your compiler,
- the macro [macroref BOOST_TEST_NO_RANDOM_DATASET_AVAILABLE `BOOST_TEST_NO_RANDOM_DATASET_AVAILABLE`]
- will be automatically set by the __UTF__]
- It is possible to construct a random sequence using the factory [funcref boost::unit_test::data::random], available in the overloads below:
- ``
- auto rdgen = random(); // uniform distribution (real) on [0, 1)
- auto rdgen = random(1, 17); // uniform distribution (integer) on [1, 17]
- // Default random generator engine, Gaussian distribution (mean=5, sigma=2) and seed set to 100.
- auto rdgen = random( (data::seed = 100UL,
- data::distribution = std::normal_distribution<>(5.,2)) );
- ``
- Since the generated datasets will have infinite size, the sequence size should be narrowed by combining the dataset with another
- one through e.g. a /zip/ operation.
- [tip In order to be able to reproduce a failure within a randomized parameter test case, the seed that generated the failure may be
- set in order to generate the same sequence of random values.]
- [h5 Parameters]
- The details of the named value parameters is given in the table below.
- [table:id_range_parameter_table Range parameters
- [
- [Parameter name]
- [Default]
- [Description]
- ]
- [
- [`seed`]
- [(not set)]
- [Seed for the generation of the random sequence.]
- ]
- [
- [`distribution`]
- [Uniform]
- [Distribution instance for generating the random number sequences. The `end` value is not included in set of values returned
- by the generator for real values, and is included for integers. ]
- ]
- [
- [`engine`]
- [`std::default_random_engine`]
- [Random number generator engine.]
- ]
- ]
- [bt_example dataset_example63..Declaring a test with a random sequence..run-fail]
- [endsect] [/ Datasets generators]
- [endsect]
|