This change adds a bisq.properties file to apitest/src/main/resources,
and makes sure it is copied to regtest/dev bisq instances' app data dirs
before they are started. By default it is empty, but can be used to
override default BisqApp options during ad-hoc testing.
The change was necessary because the core's bisq.properties resource is
not copied to test harness bisq instance's regtest data dirs during a normal
build.
Method was added on the false assumption `PaymentAccount#hasMultipleCurrencies()`
would not always return a correct value when a `PaymentAccount` instance is created
via reflection. But `hasMultipleCurrencies()` will work as long as appropriate
PaymentAccount subclasses continue setting their `tradeCurrencies` fields within
their default constructors.
Ad-hoc API testers need to be able to run the test harness without
interference from the production api method call rate meters.
This change overrides and disables most call rate meters when the
test harness is run from the ApiTestMain driver (no jupiter tests).
A newly created offer has no OpenOffer+State (AVAILABLE || DEACTIVATED)
when displayed in the CLI's console. This change adds a 'bool isMyPendingOffer'
to the OfferInfo proto + wrapper, and the CLI's console offer output formatter
uses it to determine if it should display a new offer's Enabled column value
as PENDING, instead of an ambiguous NO value.
The test harness is compatible with bitcoin-core 0.19, 0.20, 0.21.
Also removed some unnecessary comments about registering dispute
agents in the test harness because it now happens by default.
- Added CreateBSQOffersTest, TakeBuyBSQOfferTest, TakeSellBSQOfferTest.
The first tests bsq offer creation, the second & third test bsq trade
protocol, and includes bsq payment verification checks.
- Made test dispute agent registration a test harness opt.
It was a test case option, now it happens by default.
- Moved some global test constants into ApiTestConfig.
Adjusted affected test cases.
This new api testcase can run long series' of regtest trades by looping
over modified TakeBuyBTCOfferTest and TakeSellBTCOfferTest cases. The
purpose is to help reproduce problems and isolate bugs Bisq's core and
api layers.
LongRunningTradesTest is not enabled by default; it will not run in a
default test environment (such a Travis CI). Enviornment variable
LONG_RUNNING_TRADES_TEST_ENABLED must exist for the test to run.
The env variable can be set in a bash shell before running the test
case in a shell (using a gradle command), or the environment variable can
be set in an Intellij test launcher's Evironment variables field.
The modifed (short running) TakeBuyBTCOfferTest and TakeSellBTCOfferTest
cases run as before.
Changes include:
- Add static boolean isLongRunningTest to AbstractOfferTest.
- Add looping control Supplier maxTradeStateAndPhaseChecks to AbstractTradeTest.
It uses the isLongRunningTest flag in the superclass to help define the
wait times for trade state/phase changes during short and long running tests.
- Made AbstractTradeTest assert(true, trade.isDepositPublished) conditional upon
isLongRunningTest value. Long running trade test asserts have to be looser due
to increasing latency of wallet, offer and trade operations in the server as the
trade counts increase.
- Overload ApiTestCase#startSupportingApps with additional flag:
startSupportingAppsInDebugMode. Default is false. This makes
starting background apps in debug mode a bit more convenient
and self explanatory.
Make it clear the user needs to enter a two letter country code
in json form's "country" field, not a country name.
The json form's field name was not changed to "countryCode" in
this change for the following reason:
The API's payment account forms are dynamically generated using
reflection, and PaymentAccount class hierarchy @Setter methods
determine which form fields are included or excluded. Reflection
and @Setter methods are also used when reading completed json
forms, to set the field values on a new PaymentAccount instance
before it is persisted.
CountryBasedPaymentAccount subclasses have a country field and a
@Setter, not a countryCode field, hence this shortcut to informing
the user the country field value is a country-code.
Make it clear the user needs to enter a two letter country code
in json form's "country" field, not a country name.
The json form's field name was not changed to "countryCode" in
this change for the following reason:
The API's payment account forms are dynamically generated using
reflection, and PaymentAccount class hierarchy @Setter methods
determine which form fields are included or excluded. Reflection
and @Setter methods are also used when reading completed json
forms, to set the field values on a new PaymentAccount instance
before it is persisted.
CountryBasedPaymentAccount subclasses have a country field and a
@Setter, not a countryCode field, hence this shortcut to informing
the user the country field value is a country-code.
