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.
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.