Makes sense only if you assume building software is like building a house. Imagine getting an author to tell you when the novel they are writing will be finished?
Or this: imagine seeking an estimate on when a house will be built, trimmed, painted, furnished, decorated, and filled with every item needed practically and for comfort by the homeowner.
It’s a living process that requires continuous reassessment of priorities and scope, and in fact never finishes when you consider the life of the home.
I've worked on a service that handled credentials where we added tests like this to try to catch if a log statement gets added containing the username/password. We used a few end to end tests rather than attempting to include something like this is the unit tests for every function.
Our tests would set up the app's full context, get a hook into the logging framework to watch for log statements, then make requests to the service containing a set of dummy credentials, like { username: "foo", password: "bar" }. If a log statement containing "foo" or "bar" was detected the test failed.
It's not going to catch every type of issue, but at least some potential footguns can be preventing this way.