Every damn day. It’s the thing that puts me most at risk of falling out of love with software engineering.

I had a take home test a year or two ago and I got grilled during the interview for not writing crap like that.

How would you unit test that?

This was in django, where a good such test would set up the database, call the function, then check that the new state in the database is as expected.

(Which IIRC is what I changed it to)

I've seen tests like that ("has the mock been called")... and in general I've felt that they were kinda useless.

Thinking about the original TDD approach -- red, green, repeat maybe it's not that bad? I prefer your approach, where you actually verify the state change. But in the absence of that, I wouldn't mind the "call the mock" approach. At least it does change some of the contract?

I would say it's worse than no test, because it discourages refactoring. Any alterations would make the test fail, even if it still does what it's supposed to do.

It’s better than no test because it makes the metric go up, and as we all know, virtuous and rational engineering practice is about recognizing that metrics are the objective truth about The Good and anything else is just your opinion. /s

I've got mixed feelings about this. I'm leaning towards agreeing with you, because testing for the most part should be about the contract and not specific implementation. However in rare cases, as part of early development phase perhaps, I could see this being a useful signal. Provided it gets refactored later on.

I suppose having lots of mocks is a smell after all..