3c4731a676
Curtail the occurrence of order books that are blocked by reduced offers with the implementation of the fixReducedOffersV1 amendment. This commit identifies three ways in which offers can be reduced: 1. A new offer can be partially crossed by existing offers, so the new offer is reduced when placed in the ledger. 2. An in-ledger offer can be partially crossed by a new offer in a transaction. So the in-ledger offer is reduced by the new offer. 3. An in-ledger offer may be under-funded. In this case the in-ledger offer is scaled down to match the available funds. Reduced offers can block order books if the effective quality of the reduced offer is worse than the quality of the original offer (from the perspective of the taker). It turns out that, for small values, the quality of the reduced offer can be significantly affected by the rounding mode used during scaling computations. This commit adjusts some rounding modes so that the quality of a reduced offer is always at least as good (from the taker's perspective) as the original offer. The amendment is titled fixReducedOffersV1 because additional ways of producing reduced offers may come to light. Therefore, there may be a future need for a V2 amendment.
Unit Tests
Running Tests
Unit tests are bundled in the rippled executable and can be executed using the
--unittest parameter. Without any arguments to this option, all non-manual
unit tests will be executed. If you want to run one or more manual tests, you
must specify it by suite or full-name (e.g. ripple.app.NoRippleCheckLimits or
just NoRippleCheckLimits).
More than one suite or group of suites can be specified as a comma separated
list via the argument. For example, --unittest=beast,OversizeMeta will run
all suites in the beast library (root identifier) as well as the test suite
named OversizeMeta). All name matches are case sensitive.
Tests can be executed in parallel using several child processes by specifying
the --unittest-jobs=N parameter. The default behavior is to execute serially
using a single process.
The order that suites are executed is determined by the suite priority that
is optionally specified when the suite is declared in the code with one of the
BEAST_DEFINE_TESTSUITE macros. By default, suites have a priority of 0, and
other suites can choose to declare an integer priority value to make themselves
execute before or after other suites based on their specified priority value.
By default, the framework will emit the name of each testcase/testsuite when it
starts and any messages sent to the suite log stream. The --quiet option will
suppress both types of messages, but combining --unittest-log with --quiet
will cause log messages to be emitted while suite/case names are suppressed.