You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to reopen #1746. I understand that in testthat 3e it is deliberate that all messages are printed when testthat runs, and that I can handle individual messages with "supressMessages" around the function I am testing.
I find this inconvinient, especially if you suddenly add a message that affects a lot of existing tests, and then you manually have to go and put supressMessages around each individual test. This also makes the testthat code more difficult to read.
The text was updated successfully, but these errors were encountered:
I think there's a strong case to make suppressing messages the default, and if not by default, then with an option. In particular, messages should be captured and shown on failure, or discarded on success. Hadley argues in the release notes for the third edition that:
For reasons that I can no longer remember, testthat silently ignores all messages. This is inconsistent with other types of output, so as of the 3rd edition, they now bubble up to your test results. (source)
I'm not convinced that messages should be handled similarly to other output, since they are the interface by which testthat communicates results clearly to the user. By way of example, I think good unit testing libraries provide a feature to suppress printing or do it by default. For instance (from the python world):
Nose will capture (suppress) printed messages and only show them on failure. (source)
Unittest provides the -b flag which will capture output (stdout and stderr) and only display it on error.
I'll note here that this issue also re-raises #189 too.
And sometimes messages come from other packages functions called from our functions that I have no interest in seeing in my testing output.
@hydrox24 suggestion to have all output captured and displayed only if tests fail is a great option.
What is the reasoning that messages should be handled on a case by case basis? They are information for users, not relevant for testing unless we are specifically testing if a message appears.
I'd like to reopen #1746. I understand that in testthat 3e it is deliberate that all messages are printed when testthat runs, and that I can handle individual messages with "supressMessages" around the function I am testing.
I find this inconvinient, especially if you suddenly add a message that affects a lot of existing tests, and then you manually have to go and put supressMessages around each individual test. This also makes the testthat code more difficult to read.
The text was updated successfully, but these errors were encountered: