Add tests for RPC help #14020

At the moment the new test checks for:

• invalid usages
• expected output for unknown command
• current RPC command titles (derived from command categories) — this prevents adding wrong RPC categories and new categories must be added to the test

Follow up of #13945 (comment)

missing hidden category

missing test category (in Qt)

missing hidden category

It's hidden to the RPC client, and has special treatment in https://github.com/bitcoin/bitcoin/blob/2df11322faae555bd963a7610102b61049168333/src/rpc/server.cpp#L172

How can be sure, external scripts analysing C/C++ Bitcoin source code, are immune to injection?

I would prefer a C/C++ compile time security check, not an external script security check.

missing test category (in Qt)

I'm not following, in Qt?

How can be sure, external scripts analysing C/C++ Bitcoin source code, are immune to injection?

What is subject to injection here?

I would prefer a C/C++ compile time security check, not an external script security check.

There is still room to that, this test file can check for other stuff, like output is sorted, formatting.

worst, I understood only now: it looks it is working on ./bitcoin-cli help output!

I'm not following, in Qt?

I found this (as I wrote here #13945 in the p.s: anyway I was able to catch the QT command rpcNestedTest.)

in file src/qt/test/rpcnestedtests.cpp line 32:

static const CRPCCommand vRPCCommands[] =
{
    { "test", "rpcNestedTest", &rpcNestedTest_rpc, {} },
};

Anyway take care, I always configure --without-gui, I usually (read it: ALWAYS) don't take care about QT.

Oh, that doesn't matter IMO.

Thanks @promag!

Would it be an idea to assert that the actual titles are valid (i.e. not map the titles back to categories)?

I think this is more in spirit of a functional test and the test can then also assert that there are no true negatives (for example: "== Hidden ==", "== hidden ==", "== blockchain ==","== ==").

@251Labs I'll update.

@251Labs updated.

utACK 6af6d9b

Thanks @promag! Maybe a small nit would be to assert against the full category title to catch potentially missing title suffixes (==). Other than this nit LGTM.

I am not an expert about functional test, and their implementations; but I like to learn new things, that's why I am asking (maybe stupid) question.

In this kind of functional and deterministic test, wouldn't be easier simply to check the sha256 output?

$ ./src/bitcoin-cli help | sha256
2ae3a94e05bbb98323f72f19272bde01f075db16c7e4357bc46815a1393cd44a

thanks :-)

I tend to prefer like this because

• follows current convention
• more little test files is more "readable" than less bigger test files
• more files allows parallelization