3 ms·
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 -- re
by tra3 4y ago
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?
- Izkata 4y agoI 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.
- closeparen 4y agoIt’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
- tra3 4y agoI'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..