Did Kent Beck REALLY Invent TDD? | Kent Talks About TDD, TCR & Reveals One Of His BEST Ideas
HTML-код
- Опубликовано: 1 апр 2023
- Why does Kent Beck refer to himself as the 'rediscoverer of TDD'? Have you tried TCR yet? And what does Kent say is "one of his best ever ideas"?
This is a clip taken from Kent's full episode on The Engineering Room which you can watch HERE ➡️ • Kent Beck On The FIRST...
--------------------------------------------------------------------------------------
🖇 LINKS:
🔗 "TCR (Test && Commit || Revert)", Kent Beck: ➡️ • TCR test && commit || ...
🔗 "Tidy First", Kent Beck: ➡️ tidyfirst.substack.com
🔗 Small Steps - "Explore, Expand, Extract", Kent Beck: ➡️ • Video
--------------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE ➡️ bit.ly/ContinuousDeliveryPatreon
-------------------------------------------------------------------------------------
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
_____________________________________________________
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here
➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 "Test Driven Development: By Example (The Addison-Wesley Signature Series), Kent Beck" ➡️ amzn.to/2NcqgGh
📖 "Extreme Programming Explained: Embrace Change", Kent Beck ➡️ amzn.to/3K5fhg6
📖 "Implementation Patterns (Addison-Wesley Signature Series (Beck))", Kent Beck ➡️ amzn.to/3K4VWvz
📖 "Smalltalk Best Practice Patterns", Kent Beck ➡️ amzn.to/3JKyfYg
-------------------------------------------------------------------------------------
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
______________________________________________________ 
Наука
Most of today's software engineering approaches and design patterns used to be done by many developers decades ago, we just didn't have catchy names for them. Example, microservices and microfrontends, already a thing in 2008 or even earlier.
Very true: In 2006 I was working on a large system for a leading betting company where one of the modules my team had built as a monolith was growing too big and naturally showing multiple bounded contexts that could be separated. At the time, we had EJBs, which were designed for remote distribution and invocation (RMI) and systems could talk via messages (Message Beans / JMS). We had Oracle queues. We were basically breaking down our monolith into separate, independent modules, each with its own data, deployed independently, able to send async events, etc.
For me it’s difficult to know how and where to start with TDD. University didn’t mention testing even once. The first time I encountered tests was when I started working, so I’m used to writing tests afterwards and the only tests I’ve ever seen were tests written like that. Those tests check whether functions called from mocked DI services are called using an expected set of parameters and that’s done for almost everything, even when those specific function calls are not the desired result, but merely a “waystation” on the road to calculating/generating the desired result.
For a long time it has been difficult to me to grasp how I could write the tests upfront when I don’t know which methods I’m going to call and with which parameters, as I haven’t written the code yet. If I understand TDD correctly, after all this time, I don’t really need to care which functions are called unless that’s the end result I’m expecting. I would need to test the return value only, that it’s as expected, regardless of what it will take to get there. Because, while I don’t know how exactly I’ll get the result, I do know what result I want to get. Would this be the correct way to think about it?
Yes, that's a better way to think of it. I'd go slightly further, it is not that you "don't really need to care", but really DON"T TEST THAT STUFF! This couples your test, inappropriately to your solution. The goal is to have tests that can be stable as the code has the freedom to change and evolve.
I have a free tutorial if you are interested: courses.cd.training/courses/tdd-tutorial
@@ContinuousDelivery Thank you, I will definitely take a look! I'll also share this with my team, since they're the ones that are learning now, from the same codebase, how to do the same mistakes we did in the past... Hopefully we can make a change for the better :)
What drives development if not verification? There is a Dijkstra quote about having logically proven that some code is correct, one cannot verify that it works until it is run.
The most useful test tool I've used in my career was an in-house record compare program called C12RC that could compare two complicated sequential inputs in amazing ways: late 70s at the Chicago electric utility where I learned programming.
In the system and program utility context where I've spent most of my time it is more often the case that you find a test rather than write one. For a Java platform on a device there are conformance test suites for every api. But those tests are just the baseline. You also need to test real applications. But this work was more about optimisation, extending apis, and refactoring out the confusion that manifests itself as fragility or resistance to change than about generating new functionality.
I wished Kent showed a Real TDD for CRUD. He could set an industry standard
Funnily enough, I describe that in this video, it is not exactly what you asked for, but it is pretty close, and as I say in the video, I think that you, and the person I am responding do in the video, are asking the wrong question: ruclips.net/video/_gteHp-ZR9k/видео.html
@@ContinuousDelivery Thank you for your answer :) May I ask why my question is wrong? or rather what is the right question?
@@user-ig9jh6ff3m "CRUD" is an implementation detail, not really a good way to structure requirements or testing. Good TDD tests express a need, that needs to be fulfilled, CRUD isn't a need, it is an approach to a solution.
Dave, I like the content, but I find the moving parts in the background very distracting, can you please try using a static background in these dialogue-style videos?
Wow I’ve been doing TCR by accident!
That tickled me... "i don't care! I'm not your PRIEST!"
No. Kent did not invent it but he managed to turn it into a religion.
And yet he says "I don't care, I'm not your priest!"
People who use TDD: This is a great technique that greatly improves my ability to write quality software.
Other people: Oh, so you're saying I *HAVE* to follow TDD or else I'm a lousy excuse for a programmer? You zealots are all the same.
@@michaelpastore3585 when one say it improve his/her ability to write quality software, it means that how it has help him/herself and shares it to encourage others. It does not imply those that does not practice to write lousy or good code. If the person feels that way just because someone share about his/her experience... Then, does it mean the person is self admitting? Hm....
When someone say they practice clean code and it improves the code readability and maintenability, then what should those people that don't practice it think what it means??? Hm....
This same applies to everything else, when people shares their experience and how it help them improve, and people who don't practice them think negatively... Hm....
@@michaelpastore3585 TLDR Yes, you are! :)
TDD is not just about test coverage. It is about design, it is about ease of testability, it is about high cohesion and low coupling. It is about SOLID. It is about a safety net, when you have to refactor a year later. The fact that your software is well tested at the end is just a side effect.
I’m not sure where you got the idea that Beck turned TDD into a religion. He sent the exact contrary message in the video. It’s not a religion, apply it if you find it useful for your specific context. Not sure who the “TDD people” are. I see a lot of variety among people in the way they apply TDD. There are different schools and degrees of application of TDD. The idea is always to try what worked for others, see if it works for you. If it does, great. If it doesn’t…. great!
Level of selfishess here is at GOD maximum. I like how they always talk but 0 real code or examples provided))))))) and this across all channels like this)
Dave has a course you can buy where he teaches the techniques