ACK, from talking with @MarcoFalke it seems that his/bluematt's fuzzing work has superseded this

I may be a minority, but I run them on every build multiple times a day. Still meaning to review #14430.

ACK. unit and fuzz tests are sufficient.

The tests here are better written as unit tests, in which case they also run on all platforms and all dev machines.

I may be a minority, but I run them on every build multiple times a day. Still meaning to review #14430.

I looked over them and they are better suited either as unit or fuzz tests. If you plan to go over this pull, you could move and transpile them to the appropriate unit test of fuzz test file.

It looks like even travis isn't running the property based test. Unit and fuzz tests are run with sanitizers or valgrind turned on. So instead of wasting effort on an experimental and mostly not even compiled testing solution, we should streamline our effort one two that are already widely supported and run.

My impression was that PBT could find different edge cases and stress the code differently from unit tests (which only cover the cases the programmer thought of) and fuzzing, which looks for crashes from inputs. I understand not wasting time and don't want to obstruct consensus, but it might be worthwhile to leave them for any additional coverage they may provide in the future.

I just can't imagine that property based tests could ever come up with more coverage than our unit or fuzz tests can povide.

Let's look at this example:

RC_ASSERT(!(key1 == key2));`

where the key is generated by this:

            CKey key;
            key.MakeNewKey(true);

The unit test would look like:

CKey key1, key2;
key1.MakeNewKey(true), key2.MakeNewKey(true);
BOOST_CHECK(!(key1 == key2));

I mean if someone comes along and has a great test case that can only be achieved with property based tests, sure I am happy to keep them along. But this hasn't happened in the last three years, nor will it happen in the next three years. And if it did, we can always reconsider and call git revert bafc471a994948e1f4c64bbea101da200347b0eb.

Concept ACK: keeping an inactive rapidcheck integration around does not feel meaningful

If someone in the future comes up with an example where a rapidcheck test outperforms standard coverage-based fuzzing we can always revert this change.

ACK, from talking with @MarcoFalke it seems that his/bluematt's fuzzing work has superseded this

Is @TheBlueMatt fuzzing Bitcoin Core without sharing his fuzzing harnesses with us? :D

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• net: Add NAT-PMP port forwarding support #18077 (net: Add NAT-PMP port forwarding support by hebasto)
• UI external signer support (e.g. hardware wallet) #16549 ([WIP] UI external signer support (e.g. hardware wallet) by Sjors)
• External signer support - Wallet Box edition #16546 ([WIP] External signer support - Wallet Box edition by Sjors)
• Multiprocess build support #16367 (Multiprocess build support by ryanofsky)
• util: add RunCommandParseJSON #15382 (util: add runCommandParseJSON by Sjors)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

ACK 9e071b0

Property based testing only gets interesting over fuzzing when you get in the realm of state-machine testing. ie. generating a random sequence of actions/api calls and checking them against a model of what you expect the state to be (see https://www.youtube.com/watch?v=zi0rHwfiX1Q).

rapidcheck didn't seem like the greatest library either.

ACK

Property based testing only gets interesting over fuzzing when you get in the realm of state-machine testing. ie. generating a random sequence of actions/api calls and checking them against a model of what you expect the state to be

This is one of the strengths of fuzzing. See for example the fuzzer to find the money printing consensus failure #17860 .

The utxo set is the state and the maximum money supply is the condition you check.
The actions are

enum class Action : uint8_t {
    CREATE_INPUT, //!< Append an input-output pair to the last tx in the current block
    CREATE_TX,    //!< Append a tx to the list of txs in the current block
    CREATE_BLOCK, //!< Append the current block to the active chain
};

TLDR property based testing is fuzz testing

Yes from the code you linked it looks like we're already doing a form of property based testing using FuzzedDataProvider. Good stuff!