"There is not one TDD proponent who has spoken intelligibly about testing."
Best of luck with that then.
@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 😂
That's why you iterate. I have no idea what the implementation will look like, so I start with some test. Often a guiding test. It teaches me about the API I might want. As I expand the code and tests I rearrange it all frequently as I learn.
Type driven development is also cool but I think mostly complementary to tests.
@faassen @jasongorman yeah, I think the truth lies in nuanced understanding of why we do things that we do. This is a banger approach by a mature and diligent developer.
I lack diligence and I spend (probably more time than you) on refactoring interfaces rather than proactively mocking.
You know, this conversation makes me think that when I was young I didn't understand TDD because I didn't have enough experience and I thought that mocks are a replacement for e2e. Then I got disillusioned in the misconception, which resulted in behavioural apprehension lasting second decade now. 😂
@jonn @jasongorman I'm not a huge fan of mocks. I mock when it's an external well-defined thing (which I might create for the purposes of decoupling) otherwise I try to test at the highest layer where it's still easy to test.
I like getting the types right as well, and this too teaches me about how to structure things.