Unit tests as documentation

Obviously this is slightly implementation dependent but if your tests are accompanied by programmatic documentation (that is output together with the test), doesn't that eliminate the need for a descriptive test name in the first place?

If anything, in this scenario, I wouldn't even bother printing the test names, and would just give them generated identifier names instead. Otherwise, isn't it a bit like expecting git hashes to be meaningful when there's a commit message right there?

The article addresses this: there's no systematic enforcement of documentation currency. It may accidentally and unbeknownst to its authors become outdated.

Anyways, as already mentioned earlier: unit tests are code and all quality criteria that apply to any other code apply to unit tests too. We expect identifiers used in code to help understand the code no matter if it's the name of a unit test or any other entity in our program.

NB. To me this argument seems as bizarre as disputing washing your hands after using the bathroom. Why would anyone think that they should get a pass on code quality standards when writing unit tests? This just doesn't make sense...

Replying slightly late as I didn't see this on time ...

But I don't get the argument. Perhaps we're talking about different things (or have different mental anchors in mind)?

Giving python unittest syntax as an example, how does having a test called

  def test_myMethod_caseWhereZeroInputsAreGiven(): ...

provide better currency / documentation guarantees than

  def test_case000135():
      """
      Tests: myMethod
      Date: 2024-10-23
      Commit base: edb78go9
      Summary: Tests case where zero inputs are given.
      Details: ...
      """

As for quality criteria, I'm not necessarily claiming the naming scheme is overwhelmingly better, but except in the very limited and unrealistic scenario where you only need to write a single test per method, unwieldy test method names can cause more confusion than clarity, so I don't think index-based naming schemes complemented by documentation headers are 'worse' either. I don't think the standard good variable naming rules apply much here, because in general variable names largely rely on context to be meaningful, and should only be as minimally descriptive as required to understand their role in that context, whereas a test needs to be sufficiently descriptive to describe what is being tested AND provide the necessary context.

I don't think the bathroom analogy is good here either. I'm not arguing for sloppiness or bad code hygiene. A "better" analogy would be someone complaining about people not using the provided towels like people have always been doing, when the initial argument is that the towels in this particular room seem dirty and there's a perfectly fine airdryer "right there". Hence the answer "why does anyone think they get a pass washing their hands on a towel" just sounds bizzare to me, when the topic is appropriateness of sanitation method, not cleanliness itself.

(note: not being argumentative, I hope my tone does not come across as such; if you do bump onto this again and think I'm misinterpreting or missing some finer point entirely, I'd be interested to hear it)