Unit tests as documentation

I share this ideal, but also have to gripe that "descriptive test name" is where this falls apart, every single time.

Getting all your teammates to quit giving all their tests names like "testTheThing" is darn near impossible. It's socially painful to be the one constantly nagging people about names, but it really does take constant nagging to keep the quality high. As soon as the nagging stops, someone invariably starts cutting corners on the test names, and after that everyone who isn't a pedantic weenie about these things will start to follow suit.

Which is honestly the sensible, well-adjusted decision. I'm the pedantic weenie on my team, and even I have to agree that I'd rather my team have a frustrating test suite than frustrating social dynamics.

Personally - and this absolutely echoes the article's last point - I've been increasingly moving toward Donald Knuth's literate style of programming. It helps me organize my thoughts even better than TDD does, and it's earned me far more compliments about the readability of my code than a squeaky-clean test suite ever does. So much so that I'm beginning to hold hope that if you can build enough team mass around working that way it might even develop into a stable equilibrium point as people start to see how it really does make the job more enjoyable.

> It's socially painful to be the one constantly nagging people about names, but it really does take constant nagging to keep the quality high.

What do test names have to do with quality? If you want to use it as some sort of name/key, just have a comment/annotation/parameter that succinctly defines that, along with any other metadata you want to add in readable English. Many testing frameworks support this. There's exactly zero benefit toTryToFitTheTestDescriptionIntoItsName.

> What do test names have to do with quality?

The quality of the tests.

If we go by the article, specifically their readability and quality as documentation.

It says nothing about the quality of the resulting software (though, presumably, this will also be indirectly affected).

> The quality of the tests.

Very insightful, thanks.

Not sure if you felt I was being snarky, but I wasn't.

The article is discussing the quality of the tests, not quality in general and not the quality of the resulting software.

That was my point.

Saying 'stuffing a test description into the function name improves test quality because it improves test quality' is a cyclical, useless statement.

> The article is discussing the quality of the tests, not quality in general and not the quality of the resulting software.

All of my comments in this thread are about unit tests and test quality, not general software quality.

> That was my point.

I still don't see any valid point being made.

Sorry, I replied to you because I thought you were asking how it affected the final product, and I clarified, in case you had missed it, that it was about the quality of the tests as documentation.

Sorry this whole thing seems to upset you so much. Chill!