This provides:
- more
MoneyRangetests; - new
CFeeRateconstructor tests with zero byte size; - explicit using of the
CAmounttype.
This provides:
MoneyRange tests;CFeeRate constructor tests with zero byte size;CAmount type.
This provides:
- more `MoneyRange` tests;
- new `CFeeRate` constructor tests with zero byte size;
- explicit using of the `CAmount` type.
explicit using of the CAmount type.
Why? Is there an advantage?
Why?
Is there an advantage?
It clearly shows what type of return value we are expecting from the methods being testing.
utACK 29ed2d6.
Is the eventual goal to remove the implicit conversion from other types to CAmount
I hope so, right now this would remove testing of implicit conversions... is that a good thing?
@sipa @jb55 Thank you for your reviews.
Is it worth to just add an explicit test case for type conversions like this:
BOOST_AUTO_TEST_CASE(CAmountTypeConversionTest)
{
BOOST_CHECK_EQUAL(CAmount(-MAX_MONEY), -MAX_MONEY);
BOOST_CHECK_EQUAL(CAmount(-1), -1);
BOOST_CHECK_EQUAL(CAmount(0), 0);
BOOST_CHECK_EQUAL(CAmount(1), 1);
BOOST_CHECK_EQUAL(CAmount(MAX_MONEY), MAX_MONEY);
}
or just keep in mind that https://github.com/bitcoin/bitcoin/blob/fa84723e73d3d7766e7821881ac96ec203e50efc/src/amount.h#L12
Is it worth to just add an explicit test case for type conversions like this:
I don't think so—because at the same time that would be worth testing (e.g. CAmount becomes an actual type instead of typedef), implicit conversion will be no longer possible
utACK 29ed2d64f6d03e242068589ba35805b3fd2ad05a
utACK 29ed2d64f6d03e242068589ba35805b3fd2ad05a