Test Driven Development: That’s Not What We Meant • Steve Freeman • YOW! 2017
Вставка
- Опубліковано 1 чер 2024
- SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ua-cam.com/users/GotoConf...
This presentation was recorded at YOW! 2017. #GOTOcon #YOW
yowcon.com
Steve Freeman - Software Consultant, Specialising in Agile development
ABSTRACT
Test-Driven Development (TDD) has been so successful that it’s now unfashionable. But many developers complain that being required to write tests just gets in the way of shipping features. That wasn’t our experience when we first stumbled onto TDD a dozen years ago, so what went wrong? Were we fooling ourselves, or did the message get confused along the way?
In this talk, I will revisit the basics, the essence of what makes TDD work. I will look at some of the common difficulties that I see with teams that are struggling. I will show how understanding the principles means that we can use tests to help us deliver more effectively. [...]
RECOMMENDED BOOKS
Steve Freeman & Nat Pryce • Growing Object-Oriented Software • amzn.to/3tOq45w
Saleem Siddiqui • Learning Test-Driven Development • amzn.to/35OMb3n
Roy Osherove • The Art of Unit Testing • bit.ly/3obiKNB
Kent Beck • Test Driven Development • amzn.to/36kchvd
/ gotocon
/ goto-
/ gotoconferences
#TDD #TestDrivenDevelopment #Programming #Testing #UnitTesting #SteveFreeman #YOWcon
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter - Наука та технологія
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.
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.
ua-cam.com/video/EZ05e7EMOLM/v-deo.html
That manager also was the only person I ever saw delete hundreds of tests to improve life in the trench.
Ian Cooper's talk is great. May i recommend you another great one from Dave Farley ua-cam.com/video/QFCHSEHgqFE/v-deo.html&ab_channel=ContinuousDelivery ?
@@alekseykostyuk3806 Certainly! Thank you (love that UA-cam hid the Watch Later button)
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.
Coopers talk is excellent. Lot of gems in that talk, "tests protect something", don't protect implementation, protect behaviour
@@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.
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.
but there is no reason to not TDD either
I wouldn't get on a plane where the individual components hadn't been tested before putting them in the airplane.
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.
also, what does YOW stand for? 😀
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!
The ADHD is real. Great talk nonetheless.