We don't need to put this much responsibility on test names. If there is more to explain, write a few words in a comment.
In tests, however, I prefer not to have them as my favorite test runners replace the full name of the test method with its docstring, which makes it a lot harder to find the test in the code.
def matriculate_flange(via: Worble):
"Matriculates flange via a Worble."Test function names are less sensitive than regular functions, since they're not explicitly called, but I still don't want to read a_sentence_with_spaces_replaced_by_underscores.
As far as whether or not people do a better job with descriptive test function names, what I've seen is that they do? I of course can't share any data because this is all in private codebases, so I guess this could quickly devolve into a game of dueling anecdotes. But what I've observed is that people tend to take function names - and, by extension, function naming conventions - seriously, and they are more likely to think of comments as expendable clutter. (Probably because they usually are.) Which means that they'll think harder about function names in the first place, and also means that code reviewers are more likely to mention if they think a function name isn't quite up to snuff.
And I just don't like to cut those sorts of human behavior factors out of the picture, even when they're annoying or hard to understand. Because, at the end of the day, it's all about human factors.
I was talking specifically about a `def test_displays_error_message_when_refresh_times_out()` function.
That's too big a name for me to keep in my head, so I'd look for other solutions.
pytest does not though.
How are they, in practical reality, better than comments?
The way we work, it's just a different comment syntax. I do like have a dedicated place for it.
All Python programmers already benefit from the docstrings written in the libraries they use, which generate tooltips and documentation websites.
prior to mypy/type hints it allowed you to document the types of a function