I am running unit tests written by someone else, and the output is littered with print statements. I know libraries are not supposed to contain print statements, but is it bad practice for tests to contain them? My take is that they shouldn't, and asserts and other comparison statements should be employed.
Not sure that this is relevant, but the codebase is in Go.
Best Answer
Let's take a step back. We use printing / logging so we can diagnose what is going on under a particular code flow, such that we can take a look back at wherever these logs are being aggregated to see what happened at a past time.
We use tests to assert that a particular code flow operates as expected. This can be for an isolated part of the code flow (a unit test) or a broader part of the code flow encompassing multiple moving parts (an integration test). Having assertions within these tests is like logging in that it generates output about a particular code flow. I'd say that we can compare this to structured logging, since these outputs are standardized and can be parsed, along with the test processes having meaningful error codes. For example. unittest-xml-reporting parses unittest.
This all contributes to these types of tests being automated, their protocol is standardized. My question for you is, what do you want to accomplish by having print statements in your tests?
If it's for a sanity check, realize that this can be made into a formal assertion instead. Also consider that these tests are usually automatically invoked (such as from a build server), and often if they run successfully their outputs won't be dived into. Attempting to parse a print statement if you do wish to automate this sanity check should not be favored over formal assertion on whatever the print statement was printing in the first place.
If it's to say what a test is doing, this comes down to naming tests properly instead of printing some description during the test's execution.
I think these two intents cover what a print statement would potentially do, so you should consider what scenario you have and adapt accordingly.