-
Notifications
You must be signed in to change notification settings - Fork 63
Simplify output handling in unit tests #494
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
Changes from all commits
5c16be4
b49ec54
0a635e8
5d3e224
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -67,17 +67,12 @@ typedef int32 bool; | |
| #endif | ||
| typedef uint8 bool8; | ||
|
|
||
| // By default, platform_default_log() messages are sent to /dev/null | ||
| // and platform_error_log() messages go to stderr. | ||
| // | ||
| // Use platform_set_log_streams() to send the log messages elsewhere. | ||
| typedef FILE platform_log_handle; | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Excellent idea to remove these from the public api.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 |
||
| extern platform_log_handle *Platform_default_log_handle; | ||
| extern platform_log_handle *Platform_error_log_handle; | ||
| typedef FILE platform_log_handle; | ||
|
|
||
| // Set the streams where informational and error messages will be printed. | ||
| // By default, info messages sent from platform_default_log() go to /dev/null | ||
| // and error messages sent from platform_error_log() go to stderr. | ||
| // | ||
| // These default to /dev/null and stderr, respectively. | ||
| // Use platform_set_log_streams() to send those log messages elsewhere. | ||
| // | ||
| // For example, to send info messages to stdout and errors to stderr, run: | ||
| // platform_set_log_streams(stdout, stderr); | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -234,23 +234,15 @@ CTEST2(btree_stress, test_random_inserts_concurrent) | |
| if (!iterator_tests( | ||
| (cache *)&data->cc, &data->dbtree_cfg, root_addr, nkvs, data->hid)) | ||
| { | ||
| platform_default_log("invalid ranges in original tree\n"); | ||
| CTEST_ERR("invalid ranges in original tree\n"); | ||
| } | ||
|
|
||
| /* platform_default_log("\n\n\n"); */ | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not so sure about deleting this dead code and the old lines on L249 onwards below. Seems like the code author had felt a need that this kind of debugging would be handy if ever this one had to troubleshoot failures in this test's execution. I'm generally tolerant about such code being left behind, as it does help some future engineer who might have to debug this stuff. (Rob didn't complain, surprisingly ... as he's the author.) What if we (a) either retain this dead-code in comments or (b) enclose it under if (FALSE) { }? The code is there for troubleshooting and doesn't get in anyone's way.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I strongly dislike dead code. I'm going to delete it. No one is speaking up to claim this code as theirs, and I'm guessing it could be added back by someone who's making changes. |
||
| /* btree_print_tree((cache *)&cc, &dbtree_cfg, root_addr); */ | ||
|
|
||
| uint64 packed_root_addr = pack_tests( | ||
| (cache *)&data->cc, &data->dbtree_cfg, data->hid, root_addr, nkvs); | ||
| if (0 < nkvs && !packed_root_addr) { | ||
| ASSERT_TRUE(FALSE, "Pack failed.\n"); | ||
| } | ||
|
|
||
| /* platform_default_log("\n\n\n"); */ | ||
| /* btree_print_tree((cache *)&cc, &dbtree_cfg, | ||
| * packed_root_addr); */ | ||
| /* platform_default_log("\n\n\n"); */ | ||
|
|
||
| rc = query_tests((cache *)&data->cc, | ||
| &data->dbtree_cfg, | ||
| data->hid, | ||
|
|
@@ -493,7 +485,7 @@ pack_tests(cache *cc, | |
| if (!SUCCESS(btree_pack(&req))) { | ||
| ASSERT_TRUE(FALSE, "Pack failed! req.num_tuples = %d\n", req.num_tuples); | ||
| } else { | ||
| platform_default_log("Packed %lu items ", req.num_tuples); | ||
| CTEST_LOG_INFO("Packed %lu items ", req.num_tuples); | ||
| } | ||
|
|
||
| btree_pack_req_deinit(&req, hid); | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -79,6 +79,19 @@ struct ctest { | |
| unsigned int magic; | ||
| }; | ||
|
|
||
| // If FALSE (default), then CTEST_LOG_INFO() and CTEST_LOG() will no-op. | ||
| extern _Bool Ctest_verbose; | ||
|
|
||
| // For immedate logging to stdout | ||
| // (contrast with CTEST_LOG which does buffered/delayed logging to stderr) | ||
| #define CTEST_LOG_INFO(...) \ | ||
| do { \ | ||
| if (Ctest_verbose) { \ | ||
| fprintf(stdout, __VA_ARGS__); \ | ||
| fflush(stdout); \ | ||
| } \ | ||
| } while (0) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Minor suggestion. It is sufficient if you code this multi-line macro simply as:
Missing
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That seems dangerous to me. Suppose someone forgets the CTEST_LOG_INFO("foo")
something_important();With the But with your proposed |
||
|
|
||
| /* | ||
| * Global handles to command-line args are provided so that we can access | ||
| * argc/argv indirectly thru these global variables inside setup methods. | ||
|
|
||
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.
Any reason to make this an environment variable instead of a command-line option?
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.
Yeah, a flag would be preferable for ease of typing and for discoverability. I just couldn't figure out how to make it work: the interactions between
unit/main.c,config.h,unit/config_parse_test.c, andunit/splinter_test.cwere just too messy for me to untangle in the couple hours that I spent on this. I'd welcome some help on that from @gapisback or anyone else.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.
+1, that would be ideal, but I can see why that would be tricky. Future work.
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.
@rosenhouse -- I'll need to think this through with you. Am looking at the diffs now and pondered over how to achieve what you want.
Some time ago, I had added this
--verbose-progressoption that was used initially infunctional/splinter_test.cto do some verbose progress reporting while large test workloads run. This arg is parsed and tracked as aboolintest_exec_config->verbose_progress.With some work we could co-opt this flag to also mean what this
VERBOSE=1env-var wants to do. This boolean field may be the replacement for your newly-addedCtest_verbosityflag.I'm not entirely sure that this scheme will work to meet all the requirements this change-set is bringing-in. (For instance, the functional tests still seem to spit out messages to
stdouteven whenVERBOSEis not set. I'm a bit confused as to what the expected design is with regards to outputs from tests with this and your previous commit at SHA d2e9e86.)If there is not a great hurry to replace the new env-var with a command line arg, my suggestion is to let this change set go in as-is. And you & I can talk off-line to see how to smooth things over in future editions.
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.
Yes, we'll return to this in future work