Is it okay to leave tests in your code?

Like if I'm using print statements to test my code. Is it okay to leave stuff like that in there when "publishing" the app/program?

Edit: So I meant logging. Not "tests". Using console.log to see if the code is flowing properly. I'll study up on debugging. Also, based on what I managed to grasp from your very helpful comments, it is not okay to do, but the severity of how much of an issue it is depends on the context? Either that or it's completely avoidable in the first place if I just use "automated testing" or "loggers".

18 comments

It's never OK in my experience.
If its debug logs, call the logger instead of print, like Log.debug() or something. If its part of a test, it shouldn't be in the code itself. And it's not a feature either as you said. Neither logs nor test or feature: remove it.
It may also bite you in the ass one day if the output is stored or tested or filtered and someone wonders who added that unspecified stuff. We never print anything raw like that at my job, and if I saw this I would wonder who is printing random crap and I would remove that because its "useless for the application."
- I think “never OK” is overly proscriptive — we use the term best practice because there are less preferable solutions that are nonetheless viable — but your advice to use a proper logger is sound. Many developers don’t think to use them and they offer many benefits in terms of maintainability.
  
  Its not a best practice IMHO. Its never OK because of the 3 alternatives that exist, and because its forbidden in some regulated jobs.

The question mixes up tests and logging. You are referring to logs.
Use a good logging package. It will allow you to distinguish at least (possibly with verbosity levels)
trace
debug
information
warning
error
In production, configure the log level to be info-level or above, everything below will be hidden.
Lower levels can be useful for debugging automated tests. Possibly via a flag in production as well.
- I honestly never realised the terminology was that important (so I never put much effort into remembering any of it). Yes I meant logging. I'm having trouble understanding the rest of what you mean though.
  
  Apologies for being too cryptic/jargon. Pro tip: a real-life mentor can adapt to your level on-the-fly, if available.
  Maybe this introduction helps a bit to get an overview - from the context I expect you are on JavaScript or related.
  It's often hard to grasp why packages or techniques exist unless you ran into the problems that motivated the solution yourself.
  In this case, it's all about filtering by the severity of log messages (debug level). If the level is high, your app will show tiny bits of information. These do not need to show for every user, except if they want to enable it (via techniques like a switch/flag, environment variable or a config file).
  Config files or profiles are often used to enable/disable code parts in production or to configure how often scheduled jobs should be triggered and so on.
  Depending on your level of expertise logging stuff via the console may be just fine for the moment. In particular if you are the sole developer. Once you're annoyed by your own logs, incrementally replace the 'prints' with a library that feels comfortable or well-documented.

my team was driving me insane with leaving console.log("here") all over the place in every pr, so now we have a "no console.log" eslint rule in ci.
I guess my answer is it depends on your team. good logs are different, but imo if they're just debugging statements they shouldn't even make it into the repo let alone prod.
if it's just you, do whatever you want lol, performance is almost certainly not significant and most users should end up ignoring them anyway
- (Guessing JS / TS) I look after a moderately sized app, and still find console.log() useful sometimes. They are all protected by a Boolean, so we have authLog && console.log('something about auth') and the bools are all set in one global file. So turning debug logging on and off is very simple.
  The best thing is that when it's off, the bundler strips all the console log lines from the source, so they're not even there-but-inactive in production.

It's my opinion that typically all published apps should employ automated testing, in the form of unit tests, integration tests, and so forth.
As far as logs and print statements go, it probably depends on the context. Like, useful feedback and debug logs are usually good. But step by step test logs not so much, especially if the end user will be inundated by them.
- This is pretty good ^
  The idea that println has a a good way to test a s incorrect. It requires a testing interaction which should be avoided. Test behaviour at the exposed interface primarily, use logging/telemetry to discover dynamics.
  The exceptions are reserved for scripty things (bash has poor logging,) ones offs (1x migration) or personal tooling.

Are you familiar with automated testing? From the subject line I thought this was going to be about that, but the body of the post is something else.
- @jjjalljs @3rr4tt1c I was about to say though that if you have a print statement that you used to check something, and think you may want to check it again in the future, then you should remove it and make an automated test instead.

Great question.
There’s no universal rule against it and descriptive logs and errors are considered good practice, but one-off test statements in output are a common code smell, which isn’t a proper bug but suggests there might be one elsewhere.

Edit: use spoiler for info dump

It depends.
Whats the user impact? Do they see it on regular use? Do they see it if they look for it? Is that okay? Maybe even helpful for users to debug for themselves or to report issues to you?
Will the log statements remain useful in the future? Or is it noise both in output and code that will reduce readability and maintainability by burying more relevant things.
If they remain useful but more situational and lead to noise, consider putting them behind log levels or configuration flags (even if not app or configuration but a code flag).

It depends where.
Open source project other people will use, and may need to fix? Please leave them in! I love it when I can read the debug output, find the issue, and tell the maintainer how to fix it.
School assignment or professional setting? Take it out or replace it with an official looking "logger" (which will just be printf anyways).

In general no. They aren't even ok during development. Instead you should learn to use a proper debugger. They let you break at a certain point, inspect all the variables, step through the program.
- They're totally ok. Sometimes printf debugging is the best option. (I agree it's not an excuse to not use a real debugger though.)

18 comments