-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow asserting againt TestBase log file #384
Allow asserting againt TestBase log file #384
Conversation
Warnet RPC server itself logs to However, I see what you mean about reading old log messages. For that reason, it might make sense for us to move the warnet server log into the network-specific subfolder (there will be a new one for each test run e.g. And finally yes the addition of |
a656aa9
to
4a2948b
Compare
22bc94c
to
11c4889
Compare
2e36b8c
to
11c4889
Compare
@mplsgrant I think #385 is ready for merge, if youre done with it lets merge that then rebase this one |
c8bc830
to
9f3acea
Compare
This has been rebased. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK from me.
Just left a few comments/questions on first pass over
Assuming we go with this logging approach, I want to go in an replace the existing print statements with calls to logger. |
3c5a09d
to
d0f749a
Compare
I switched the logger config to warnet's established config json file. Also, converted all the existing print statements into logger.info. |
Great! I'd like to re-review and try to merge this before my giant refactor, I think... (also you reminded me that I should use our loggingconfig in my pr, probably) |
I think in addition to the conflict with (newly reformatted) I also slightly changed the entire log output format: https://github.com/bitcoin-dev-project/warnet/actions/runs/9846784937/job/27185339346#step:8:133 but I think that will actually not be an issue for your regex? Perhaps you can drop your first three commits here, if that one gets merged first (or visa versa)? Not checked thoroughly yet... |
d0f749a
to
3e2d110
Compare
99d7f16
to
791482b
Compare
cf63785
to
c1c6d27
Compare
This is rebased/refactored and ready to go. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced this is working... 🤔
I also re-added "since" to clear the messages. |
test/test_base.py
Outdated
if (self.log_expected_msgs or self.log_unexpected_msgs) and assert_log( | ||
message, self.log_expected_msgs, self.log_unexpected_msgs | ||
): | ||
self.log_msg_assertions_passed = True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this flag need to get reset ever? What if a test uses assert_log a few times with the same test_base instance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I imagined users setting self.log_expected_msgs
and self.log_unexpected_msgs
once per TestBase instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could reset the assertions status after checking. I updated with that concept. Need to test it.
Co-authored-by: Matthew Zipkin <[email protected]>
b50b8fa
to
c638303
Compare
This second run includes slightly modified expected and unexpected messages
c638303
to
96c7978
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 96c7978
I think this is good to go. I have 2 suggestions below you can take or leave, or apply to follow-ups...
Show Signature
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
ACK 96c7978c1e978abb3e2bd79bc7209a7cdf587350
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE5hdzzW4BBA4vG9eM5+KYS2KJyToFAmaVLLwACgkQ5+KYS2KJ
yTr1BhAArvSVNdvm92D/yStxqtkgy05PeQJVxI7X/oeleb/W2BjHq966TckyXKmA
XtnlYi0NirHqAZtldODwjPkXhDI/fYOjt0lr+nfkOtHXM6Oy0T7M7M/2fxNkxtBa
N/mCutSIH07H0s99W/RvdVPL20VINJESzxViR4VIo6LwUu7JuY2v6kNqebpyIJQ5
7XlbFCMNn/tPayqwiFhh09KoTaL7NNtpx+GeKBajGwYVFVNGkaVaahCTR8h2dKCf
SpWzR8PWWe1HhUd5SuslsLs/creHDIJv9NpGWyBq4Ne39meNQiffZe8w/HqIKF3w
RexTbSIfaNwc3HR8t2UhI1kHVXUY9IIPjXpQ71evDxlla4sgUdbSt6ohsFSPZ4oh
W4Xl6QXOz0Xe90lnoIbX2q76OEaEqNjF3d++OYtGpKfh0h2gLPjYZmaxNJZMNHFK
jFEi1gv6faW97c2ErwEiBkW2DpNFSppZeIUkcVAsAP51S2E2Ntq50zj66vkSb3IM
coWPhLuIAZ0lgEpEzyTn5SEQYcNqFuyxgKrY5AxhpMkMa5ul5nCshfPIY1DpLzC3
Jm+ZPbUniHEhQQAJ0GPku58pbKSpzynhf46cdjbLk2NdYT6+rQ113mT5KmDmaQLb
KcRNfbwInpdXFobzlDlySejCZ2QmBFaXi2U2Unnsm26/EtUVNmw=
=1aXP
-----END PGP SIGNATURE-----
pinheadmz's public key is on keybase
def assert_log_msgs(self): | ||
assert ( | ||
self.log_msg_assertions_passed | ||
), f"Log assertion failed. Expected message not found: {self.log_expected_msgs}" | ||
self.log_msg_assertions_passed = False |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ran a test with an unexpected message which aborted early, as expected. Funny thing though, because it exited early the test never got to the part where it prints the expected message. So even though its true the expected message was not found in the log, the more relevant error is the unexpected message which occurred first. I'm not sure if there's anything we really need to change about this, unless you have an idea:
2024-07-15 13:55:25 | INFO | scenario | ConnectDag PRNG seed is: 131260415370612
Exception in thread Thread-1 (output_reader):
Traceback (most recent call last):
File "/opt/homebrew/Cellar/[email protected]/3.12.3/Frameworks/Python.framework/Versions/3.12/lib/python3.12/threading.py", line 1073, in _bootstrap_inner
self.run()
File "/opt/homebrew/Cellar/[email protected]/3.12.3/Frameworks/Python.framework/Versions/3.12/lib/python3.12/threading.py", line 1010, in run
self._target(*self._args, **self._kwargs)
File "/Users/matthewzipkin/Desktop/work/warnet/test/test_base.py", line 103, in output_reader
func(line)
File "/Users/matthewzipkin/Desktop/work/warnet/test/test_base.py", line 67, in _print_and_assert_msgs
if (self.log_expected_msgs or self.log_unexpected_msgs) and assert_log(
^^^^^^^^^^^
File "/Users/matthewzipkin/Desktop/work/warnet/test/test_base.py", line 214, in assert_log
raise AssertionError(f"Unexpected message found in log: {unexpected_msg}")
AssertionError: Unexpected message found in log: Tank
2024-07-15 09:55:29 | DEBUG | test | Executing RPC method: scenarios_list_running
2024-07-15 09:55:29 | INFO | test | Stopping network
2024-07-15 09:55:29 | DEBUG | test | Executing warcli command: network down
2024-07-15 09:55:30 | DEBUG | test | Waiting for predicate with timeout 60s and interval 1s
2024-07-15 09:55:30 | DEBUG | test | Executing RPC method: network_status
2024-07-15 09:55:30 | INFO | test | Waiting for all tanks to reach 'stopped': {'total': 10, 'stopped': 9, 'running': 1}
2024-07-15 09:55:31 | DEBUG | test | Executing RPC method: network_status
2024-07-15 09:55:32 | INFO | test | Waiting for all tanks to reach 'stopped': {'total': 10, 'stopped': 10}
Traceback (most recent call last):
File "/Users/matthewzipkin/Desktop/work/warnet/test/dag_connection_test.py", line 52, in <module>
test.run_test()
File "/Users/matthewzipkin/Desktop/work/warnet/test/dag_connection_test.py", line 20, in run_test
self.run_connect_dag_scenario()
File "/Users/matthewzipkin/Desktop/work/warnet/test/dag_connection_test.py", line 39, in run_connect_dag_scenario
self.assert_log_msgs()
File "/Users/matthewzipkin/Desktop/work/warnet/test/test_base.py", line 75, in assert_log_msgs
self.log_msg_assertions_passed
AssertionError: Log assertion failed. Expected message not found: ['Successfully ran the connect_dag.py scenario using a temporary file']
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the unexpected message AssertionError gets buried in the log, and the less meaningful message not found AssertionError gets highlighted by virtue of being the last message.
To fix this, I would probably use an enum named "Found": Nothing, Expected, Unexpected, and UnexpectedExpected. Then lift the assertion call out of the assert_log helper function and plug it into the TestBase's asset_log_msgs function. Then I would have the helper assert_log functions return the enum.
re-ACK 4098f6e thanks Grant nice work |
Issue
I want to use an
assert_log
function against the output of rpc-0. Specifically, I want to assert the existence of some text that is produced by a scenario and logged by rpc-0. I don't believe that is possible today.Also, when scenarios fail today, that failure does not bubble up to the test framework.
Cause
server_thread
inTestBase
prints the log output of rpc-0, but it does not store that information anywhere in a way that allows tests to access it.server
inTestBase
reads the entire history ofkubectl log -f pod/rpc-0
which causes assert statements in test cases to incorrectly check old/stale log entries.Solution
Allow
TestBase
to examine the output of the kubectl process log and create assertions against it. Limit that log output to the current run by preventing kubectl from logging old messages by using the--since
flag.