0
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2025-02-02 09:46:52 -05:00

Merge #18305: test: Explain why test logging should be used

ffff9dcdc3 test: Explain why test logging should be used (MarcoFalke)

Pull request description:

  Background is that some tests don't have any `self.log` call at all. Thus there are no "anchor points" and those tests are hard to debug because the logs can't easily be parsed by a human.

ACKs for top commit:
  jonatack:
    ACK ffff9dcdc3
  instagibbs:
    ACK ffff9dcdc3
  fanquake:
    re-ACK ffff9dcdc3

Tree-SHA512: 08d962e85c4892c2a0c58feb5dc697c680a9d68e41a79417da6fcd415e0c5c735c4533a985cf225bb89deb5ca717d9bedf990657958079185804caa512b10f5a
This commit is contained in:
MarcoFalke 2020-03-10 12:45:30 -04:00
commit cf4cb28efc
No known key found for this signature in database
GPG key ID: CE2B75697E69A548
2 changed files with 5 additions and 2 deletions

View file

@ -145,7 +145,7 @@ levels using the logger included in the test_framework, e.g.
`test_framework.log` and no logs are output to the console.
- when run directly, *all* logs are written to `test_framework.log` and INFO
level and above are output to the console.
- when run on Travis, no logs are output to the console. However, if a test
- when run by [our CI (Continuous Integration)](/ci/README.md), no logs are output to the console. However, if a test
fails, the `test_framework.log` and bitcoind `debug.log`s will all be dumped
to the console to help troubleshooting.

View file

@ -51,10 +51,13 @@ don't have test cases for.
#### General test-writing advice
- Instead of inline comments or no test documentation at all, log the comments to the test log, e.g.
`self.log.info('Create enough transactions to fill a block')`. Logs make the test code easier to read and the test
logic easier [to debug](/test/README.md#test-logging).
- Set `self.num_nodes` to the minimum number of nodes necessary for the test.
Having additional unrequired nodes adds to the execution time of the test as
well as memory/CPU/disk requirements (which is important when running tests in
parallel or on Travis).
parallel).
- Avoid stop-starting the nodes multiple times during the test if possible. A
stop-start takes several seconds, so doing it several times blows up the
runtime of the test.