Test Driven Development: That’s Not What We Meant • Steve Freeman • YOW! 2017

[@GOTO-]

We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.

[@LukePuplett]

I've not had time to watch it all yet so excuse me if this is dealt with, or perhaps I'm plain wrong: a lot of these tests look like they're testing implementation and not the public behavioural surface area of a component. I've been coding for 35 years now and I never felt happy with groupthink TDD, and that mocking and mocking frameworks are a red flag. I've never used them in my own projects, and I've never tested my implementation code either. I do use a DI container to knit just the seams of my app together so I can isolate it. I never admitted this because there's a lot of shame in coding. But in my private projects, I've never had the problems commonly experienced in my paid projects. I put it down to not testing implementation and not using mocking frameworks but using one or two hand-written (in memory) fakes. Then an old engineering manager got us in a room and showed Ian Cooper's talk "TDD: Where did it all go wrong?" and he nails it for me. It's a must watch. kzbin.info/www/bejne/e4uTZphterKCgq8 That manager also was the only person I ever saw delete hundreds of tests to improve life in the trench.

[@alekseykostyuk3806]

Ian Cooper's talk is great. May i recommend you another great one from Dave Farley kzbin.info/www/bejne/h3emeYZ7fcykfKc&ab_channel=ContinuousDelivery ?

[@LukePuplett]

@@alekseykostyuk3806 Certainly! Thank you (love that KZbin hid the Watch Later button)

[@hannessteffenhagen61]

There isn't really much of a difference between mocking and "faking". What is certainly a red flag is abundance of mocking in tests. There's nothing really wrong with using mocking frameworks, except that they can make doing very stupid things very easy - but it's still doing the stupid thing that's the problem, not the tools you use to do them with.

[@benpurcell591]

Coopers talk is excellent. Lot of gems in that talk, "tests protect something", don't protect implementation, protect behaviour

[@LukePuplett]

@@hannessteffenhagen61 It's not the biscuits that make me fat, it's dopamine. Tools have a way of making people feel like they should be using the features, and complexity feels so wonderfully stimulating to us coders, it''s dopamine. Like the Sirens, the features of out tools beckon and lead us astray. And the tool makers, high on the success of the last feature, add further shiny ornamentation and this cycle takes us far, far off track. I don't keep sugary foods in the house.

[@yogabija]

Thanks for this, I have been doing TDD for a while now, and love it. This video is really useful to share to those who aren't convinced about TDD. So one I have shared and will share in the future.

[@Tony-dp1rl]

At the end of the day, no TDD proponent is getting on a plane that has only been Unit Tested. There is a reason for that.

[@PaulSebastianM]

but there is no reason to not TDD either

[@thatpaulschofield]

I wouldn't get on a plane where the individual components hadn't been tested before putting them in the airplane.

[@marco.garofalo]

Yes, the reason is that TDD is not a synonym of unit testing. You can TDD at the architecture level, down to the granular behaviour of a module, obviously the lower you go in the test pyramid the more cycles you can do per unit of time, because it gets cheaper and faster to RGR.

[@yogabija]

also, what does YOW stand for? 😀

[@khaliunbat-ochir]

Developers tend to become to careful over the time. Smartest of them become too nice. Hyping everything until a solution comes along doesn’t work without actual genius. And genius doesn’t show until hyping everything up. Strength of the decision decides!

[@chaitany.a]

The ADHD is real. Great talk nonetheless.