[DEV] Fix automatic unit tests Feathercoin 0.9.6 [Completed 29th Jan 2017]

wrapper

This is the last test, the test crawls through values of nHeight, or " simulated" blocknumber and accumulates nSum, up to a maximum value ( 23919999). At each 1000 “block” it does a calculation , based on COIN, a constant and the miners subsidy.

then, this cumulated value is “boost compared” to what it should be, weirdly, +ULL.

Notes :

copyright needs updating, to the FTC corrected Test files.
“Tests” needs testing to see if what happens at subsidy halving

Two separate tests were created to account for the subsidy change over on block 204639, when the block time was reduced from 2.5 mins to 1 minute, and subsidy changed from 200 to 80 …

Feathercoin/src/test/main_tests.cpp

// Copyright © 2014 The Bitcoin Core developers
// Distributed under the MIT/X11 software license, see the accompanying
// file COPYING or http://www.opensource.org/licenses/mit-license.php.

#include “core.h”
#include “main.h”

#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_SUITE(main_tests)
BOOST_AUTO_TEST_CASE(subsidy_limit_test)
{
uint64_t nSum = 0;
for (int nHeight = 0 ; nHeight < 204638; nHeight += 1000) {
uint64_t nSubsidy = GetBlockValue(nHeight, 0);
BOOST_CHECK(nSubsidy <= 200 * COIN);
nSum += nSubsidy * 1000;
BOOST_CHECK(MoneyRange(nSum));
}
for (int nHeight = 204639 ; nHeight < 23919999; nHeight += 1000) {
uint64_t nSubsidy = GetBlockValue(nHeight, 0);
BOOST_CHECK(nSubsidy <= 80 * COIN);
nSum += nSubsidy * 1000;
BOOST_CHECK(MoneyRange(nSum));
}
BOOST_CHECK_EQUAL(nSum, 33599996093750000ULL);
}
BOOST_AUTO_TEST_SUITE_END()

Wellenreiter

We should enhance the test section to test acceptance of Block version 2 and Block version 4 starting 0.9.6, but I’m not sure if that can be done within a few days. I would like to announce 0.9.6 as new production release before February.

wrapper

@Wellenreiter A test to cover the Block 2 and 4 issue is a very good idea. It should be relatively easy for @Lizhi to do, with his experience of the code and information in the tests thread and commits.

I propose we remove the Block 2 and 4 compatibility unless there is a (auto test suite) test and it passes. I would help create one. Obviously we would also need @Aciddude , it shouldn’t be that difficult …

I have created an issue. https://github.com/FeatherCoin/Feathercoin/issues/151

Wellenreiter

@wrapper said in [DEV] Fix Build Auto Tests Feathercoin 0.9.6 [Completed]:

@Wellenreiter A test to cover the Block 2 and 4 issue is a very good idea. It should be relatively easy for @Lizhi to do, with his experience of the code and information in the tests thread and commits.

I propose we remove the Block 2 and 4 compatibility unless there is a (auto test suite) test and it passes. I would help create one. Obviously we would also need @Aciddude , it shouldn’t be that difficult …

I have created an issue. https://github.com/FeatherCoin/Feathercoin/issues/151

I disagree with the removal of the Block 2/Block 4 code. 0.9.6 is planned to be the ‘bridge’ between the old and new block version, so it is essential, that it accepts both block versions.
We can do a manual test in a testnet setup to check for this release and build the automated tests for the next releases. See my comment on Github for that.

https://github.com/FeatherCoin/Feathercoin/issues/151

wrapper

Issue
I am particularly concerned that we will get support issues if we implement the “Bridge” Feathercoin Block 2/Block 4 code forward compatibility, under the current circumstances.

Mode of success
I would agree we could release a Tested version, if there were an official Feathercoin 0.11 version binary out. But current there is a possibility of the current 0.11 development version being applied to mining.

Causes of Failure
People have taken the highest number as the official version of Feathercoin in the past, causing us major problems before.

Symptom of failure
I see this as an accident waiting to happen, so if we go ahead I won’t be able to “do support issues” that arise.

Suggested Way forward

Make sure there are no ways to download a “Unofficial” Feathercoin 0.11 Binary and @Lizhi promises not to deploy test or development versions of Feathercoin 0.11 until is ready for release.

We create a higher version of Feathercoin 0.11 (i.e. 0.11.1 so any rouge binaries are not the highest release number) , which is also a Bridge version and does not try trigger a block 4 upgrade, We can then test that operates on the network ready for the “Official 0.11 release” which would allow the block change trigger…

When we change to Official 0.11 the block 4 change can be well publicized auto fork /0.8 upgrade essential fork.

Wellenreiter

The Bridge functionality is tested already, and I’d say we tested it the hard way. Last spring we had Lizhi’s 0.11.2 code starting to create Block v4 which was rejected by the 0.8.7 and 0.9.3 versions, which in turn continued to creat Block version 2, that was rejected by the 0.11.2.
The result was the fork of the BC we faced.
Ghostlander impleneted a patch for 0.8.7 into 0.8.7.3 to accept also block version 4 and Lizhi did the similar thing to 0.9.3.2.
The BC converted after these patched releases where rolled out.
I think, that was the ultimative proof, that the code is working.

Additionally Lizhi modifed the 0.11.X code to also accept Block V2 blocks.

I think we are safe here.

Now we release 0.9.6 and officially name it a bridge release to motivate users to migrate a bit faster. ;)

Regarding Lizhi’s development versions, I currently have a close look on Github and check that the production flag is set to false for any new merge/push that is made to the code.
This generates a warning in the gui and the logs that the release is non-production and should not be used for mining.

I think we hardly can do more, as anybody can fork the code, do any modification and compile/run a dangerous client.

We can’t avoid that by implementing more complex administrative measures. As long as the big majority of nodes is using the ‘official’ code, the infrastructure should cover any errors injected by a single or small number of misbehaving clients. That is part of the distributed BC.

AcidD

Staying on topic ;-)

I’ve moved this back to “In Progress” - Explanation below:

When you build Feathercoin-QT with the tests the following binaries get built

/src/feathercoind
/src/test/test_bitcoin (the feathercoind test)

/src/qt/feathercoin-qt
/src/qt/test/test_feathercoin-qt (the gui test)

I apologise but this slipped my mind and while the test program builds with no complaints…we have some interesting stuff in the console print out when we run ./test_feathercoin-qt

see below:

aciddude@osboxes:~/Feathercoin/build/bin$ ./test_bitcoin-qt 
********* Start testing of URITests *********
Config: Using QtTest library 5.5.1, Qt 5.5.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 5.4.0 20160609)
PASS   : URITests::initTestCase()
FAIL!  : URITests::uriTests() 'GUIUtil::parseBitcoinURI(uri, &rv)' returned FALSE. ()
   Loc: [uritests.cpp(16)]
PASS   : URITests::cleanupTestCase()
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted
********* Finished testing of URITests *********
********* Start testing of PaymentServerTests *********
Config: Using QtTest library 5.5.1, Qt 5.5.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 5.4.0 20160609)
PASS   : PaymentServerTests::initTestCase()
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::initNetManager : No active proxy server found.
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest : Secure payment request from  "testmerchant.org"
QDEBUG : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant : Payment request: certificate expired or not yet active:  QSslCertificate("3", "03", "LxHILx+N3qwVoAcCmQ5cyw==", (), ("Expired Test Merchant"), QMap(), QDateTime(2013-02-23 21:26:43.000 UTC Qt::TimeSpec(UTC)), QDateTime(2013-02-24 21:26:43.000 UTC Qt::TimeSpec(UTC)))
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest : Insecure payment request to  "6sMH7m11qaUoZX2coz5oe33R64eGHQCAKi"
QDEBUG : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant : Payment request: certificate expired or not yet active:  QSslCertificate("3", "03", "LxHILx+N3qwVoAcCmQ5cyw==", (), ("Expired Test Merchant"), QMap(), QDateTime(2013-02-23 21:26:43.000 UTC Qt::TimeSpec(UTC)), QDateTime(2013-02-24 21:26:43.000 UTC Qt::TimeSpec(UTC)))
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest : Secure payment request from  "testmerchant8.org"
QDEBUG : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant : Payment request: certificate expired or not yet active:  QSslCertificate("3", "06", "MiZaQ+g9lSHZGuHWkXZG+g==", (), ("Payment Request Intermediate 5"), QMap(), QDateTime(2013-02-23 22:59:51.000 UTC Qt::TimeSpec(UTC)), QDateTime(2013-02-24 22:59:51.000 UTC Qt::TimeSpec(UTC)))
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest : Insecure payment request to  "6sMH7m11qaUoZX2coz5oe33R64eGHQCAKi"
QDEBUG : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant : Payment request: certificate expired or not yet active:  QSslCertificate("3", "06", "MiZaQ+g9lSHZGuHWkXZG+g==", (), ("Payment Request Intermediate 5"), QMap(), QDateTime(2013-02-23 22:59:51.000 UTC Qt::TimeSpec(UTC)), QDateTime(2013-02-24 22:59:51.000 UTC Qt::TimeSpec(UTC)))
QDEBUG : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant : SSL error:  certificate signature failure
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest : Insecure payment request to  "6sMH7m11qaUoZX2coz5oe33R64eGHQCAKi"
QDEBUG : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant : SSL error:  certificate signature failure
QDEBUG : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant : SSL error:  unable to get local issuer certificate
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest : Insecure payment request to  "6sMH7m11qaUoZX2coz5oe33R64eGHQCAKi"
QDEBUG : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant : SSL error:  unable to get local issuer certificate
PASS   : PaymentServerTests::paymentServerTests()
PASS   : PaymentServerTests::cleanupTestCase()
Totals: 3 passed, 0 failed, 0 skipped, 0 blacklisted
********* Finished testing of PaymentServerTests *********
aciddude@osboxes:~/Feathercoin/build/bin$

I’ll see if I can put in the time to get this working before the 0.9.6 release.

Wellenreiter

I don’t think that is a problem with the test code, it complains about the SSL certificate missing. It does not fail.
I’ve never checked, where SSL really is used, but installing the correct certificate should make the test work without complains.

AcidD

@Wellenreiter said in [DEV] Fix automatic unit tests Feathercoin 0.9.6 [In Progress]:

I don’t think that is a problem with the test code, it complains about the SSL certificate missing. It does not fail.
I’ve never checked, where SSL really is used, but installing the correct certificate should make the test work without complains.

Yes you’re 100% correct. you have to actually pass it a valid certificate.

The URI tests I’ve fixed. it’s a very basic bitcoin:// to feathercoin:// will submit a PR soon.

once the URI test is fixed then all our tests are passing 100%.

AcidD

URI tests fixed in PR https://github.com/FeatherCoin/Feathercoin/pull/154

Marked as completed: 29-01-2017

wrapper

I’ll start a thread to cover the 0.11 tests, when we start moving this work over…

AcidD

@wrapper said in [DEV] Fix automatic unit tests Feathercoin 0.9.6 [Completed 29th Jan 2017]:

I’ll start a thread to cover the 0.11 tests, when we start moving this work over…

When I fixed the 0.9.6 tests I had a look at the code for Bitcoins 0.11 tests, there’s a few things that have changed so I doubt any of my test fixes will work for 0.11…not 100% sure tho.

Wellenreiter

When I fixed the 0.9.6 tests I had a look at the code for Bitcoins 0.11 tests, there’s a few things that have changed so I doubt any of my test fixes will work for 0.11…not 100% sure tho.

As long as the data used is the same, it should be ok.