1
mirror of https://github.com/bitcoin/bitcoin synced 2024-10-04 12:58:26 +02:00

test: Explain why test logging should be used

This commit is contained in:
MarcoFalke 2020-03-09 14:40:47 -04:00
parent 5518eeec27
commit ffff9dcdc3
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.