@jasongorman
The common factor in not comprehending all of them is...
@faassen @jasongorman unironically, all I heard from TDD people is like...
Translate specs to tests, before you change behaviour, change tests. But the problem is that when you don't have implementation yet, to do most kinds of tests, you need to create replace stuff "behind the interface" with something.
I think with most people (me included), there is where the problematic aspect comes into play. I'm not convinced that in we'll typed languages TDD benefits is distinguishable from just writing tight types.
But, of course, I wouldn't spew hot takes like the one quoted π
@jasongorman @faassen by doing what TDD tells me to do β writing them before the implementation! π
@jasongorman @faassen oh, but meaningful tests, according to me, are invariant tests, e2e tests, performance tests, blah-blah-blah, stuff that wants implementation (often beyond the boundaries of the interface)!
In teams I manage, I suggest reframing unit tests as *the* tool to write most of regression tests, but not as a tool to increase the evidence of even correctness.
"You wouldn't test a theorem".
@jasongorman @faassen unironically cool take! Almost a kΕan.
@jonn @faassen In one form or another, it's common to all user-centred methods. e.g., use case realisations in OOSE and RUP. In Formal Methods we'd write testable specifications for user outcomes. Then we'd write tests based on those. TDD just cuts out the middleman π