Finally a clear image of how TDD is applied in real world problems. Thanks man, that was a great explanation!
@zHqqrdz4 жыл бұрын
I just want to add another commentary that this talk is absolutely golden. It teaches a LOT MORE than you'll find in pretty much any other TDD talk. Prove me wrong please, and link me another talk of the same caliber.
@kevinfleischer20494 жыл бұрын
Check out "Improving your Test Driven Development in 45 minutes - Jakub Nabrdalik" . I found it good too. kzfaq.info/get/bejne/aNx1oq9krtjLmas.html
@MohamedCherifBOUCHELAGHEMdz234 жыл бұрын
@@kevinfleischer2049 Thank you, I'm curious to see how he used C4 model!
@wealcome_company3 жыл бұрын
Check out this one : vimeo.com/68375232. best ever
@bluebottle43 жыл бұрын
I agree. I could have listened to this guy for much longer. But nice bait, asking for similar quality material ;)
@dardanbekteshi31772 жыл бұрын
kzfaq.info/get/bejne/e8BgaMhoqrOzfIE.html here's another TDD talk of a very high caliber. Enjoy :)
@wedesoft2 жыл бұрын
Finally a talk with an answer to the question where to use mocks and how to choose your units.
@RmaxTwice Жыл бұрын
What an unbelievable amount of raw concentrated developer experience directly distilled into our brains. Bravo
@eduardocosta90785 жыл бұрын
Amazing talk in the classic old school style, a white board, a pen and the ideas bubbling up in the mind! Congrats.
@RoamingAdhocrat Жыл бұрын
Just to say I really appreciate this camera setup - the fixed view showing the whiteboard clearly, and the second view of the presenter.
@edgeeffect6 ай бұрын
It'd be better if they could improve the camera tracking. .... and the grading.... and maybe give it a miss when there's nothing to see on the whiteboard - it's quite "seasick" at that point.
@ruixue695529 күн бұрын
6:03 there are different types of TDD 6:07 classist by Kent Beck 6:16 outside-in 7:07 *emergent design* 7:52 4 rules of simple design 7:59 pass all the tests, reveal intention, no duplication, fewer elements 10:14 just-in-time design 12:04 *classist* approach 14:36 challenging problem 15:34 mock is rarely used in classist approach 15:47 beauty of this type of TDD: no upfront design 17:12 cases when there is very complex logic 17:46 18:02 feature 2 19:08 21:58 another problem when unit under tests is becominh very big 23:58 how to define the size of a unit 24:57
@TheOceanLoader Жыл бұрын
This guy wrote a book called Software Craftsmanship. It's one of my favourite books. I remember working with him at Valtech many years ago.
@shashanksharma900 Жыл бұрын
pointed out the exact point of Concern rather than beating the bush Felt very Clear and Empowered in the end Thanks Again Loved it
@jayoolong2792 ай бұрын
Such a good talk, I am sad that there wasn't enough time!!
@nikitakoselev41792 жыл бұрын
That is a mind blowing actually. One of the best talks I have seen in 2021.
@Chemaclass3 жыл бұрын
This talk is a must-watch for all devs! Thank you!
@chauchau0825Ай бұрын
I am glad he spent entire talk demonstrating TDD does not lead to good design. Good Design Decision does.
@dimitriostsobanopoulos74 жыл бұрын
Excellent talk! He practically explained what I've been using myself for the past 25 years when developing systems, always starting from a test, making the design decisions, and refactoring until requirements and domain constraints are met. My favorite part of this talk is when he briefly spoke about optimizing for the future and deciding what the inflection point should be at the current stage of the system evolution. Many times, this is a hard decision that needs to be based on a lot of business information items involving time constraints, product life-cycle expectations, future scalability and expandability, minimum initial functionality requirements, and so on, just to begin with. Many times it feels like trying to divine the future. I generally don't do the failing test part, but I do insist on strict adherence to enforcement of preconditions, postconditions, invariants, S.O.L.I.D, and this has led to very stable and scalable systems.
@cesar_zapata3 жыл бұрын
25 years. That's a long time. :D does it finally get easier after that long. Congratz man.
@dimitriostsobanopoulos72 жыл бұрын
@@cesar_zapata When I asked this same question to one of my professors back at university, he smiled and said: "I am a student of computer science, and learning does not have a visible horizon". This answer left an impression on me.
@cesar_zapata2 жыл бұрын
@@dimitriostsobanopoulos7 that's brilliant. It totally makes sense.
@rkgrachel2 жыл бұрын
Three years ago, still GREAT talk! Thanks a lot.
@hartmannsson2 жыл бұрын
Two more hours of this would’ve been great!
@youssefmourchid91492 жыл бұрын
thank you Sandro for demystifying this subject, it's a pragmatic way to practice TDD, brilliant
@matthieucneude57614 жыл бұрын
Very good talk. Some points I would like to come back: 1. I don't like when everybody like to speak about the Single Responsibility Principle. Speaking about cohesion and coupling is enough, and is self explanatory. What does the SRP is claiming that "one" reason to change should be only allowed, which is totally arbitrary and doesn't make sense because this decision depends on the context. The SRP is a useless abstraction hiding important details from the concepts coupling / cohesion. It's confusing, especially for beginners. 2. Mocking as a design decision is good. I think however that anything external you call, you should call it in its own method / function. Then, the result should be dispatched. If there is absolutely no logic in this method, there is no need to test it, so there is no need to mock these external calls. 3. Finally, I like TDD, but I never write the failing test. I know I will test what I'm doing, and I test it as the first smallest iteration of my solution. What's missing from TDD too is the "thinking" part between green and refactor. We should stop at that point, ask ourselves if the direction we take is faithful from the design we decided earlier on, fix our assumptions and continue.
@johanrg703 жыл бұрын
@@milfex-lostex3984 As soon as someone says "always" or "must" or similar statements I disagree on principle. All of those things are tools to help us write better code, but we should also know when to apply them and when not to.
@abduljeelani40403 жыл бұрын
Refactor is not only for the code but for the test as you describe in 20.45, whenever this happens we isolate C separately and its behavior separately. To fill the space we just use test double instead of mocks. No matter we do test double with pure class or mocks, It is crucial to ensure the behavior of these are consistent and matches with the original class / function. I have seen multiple code bases where the mocks for the same behaviour are spread across in multiple places, and then it gets divergent from original class. In case of another test double we add one more test for the test-double to ensure that is always up to date. Another quality of code is changing the code without affecting the behavior should not fail the test. Mockists leads you to assert Called Once, called Twice etc. which becomes a barrier in refactoring. Lesson: Use Mocks more carefully, prefer classists, Refactor your tests as well, not only the code ..:)
@lzszl2 жыл бұрын
Love the Talks, the music at the end needs the gain turned down, blew out my headphones
@aalbero Жыл бұрын
The second half of this video is simply brilliant
@F2H16 Жыл бұрын
Incredible, it's all raw experience that has been put into this talk. Hats off 👍👍👌👌
@gzoechi7 ай бұрын
For me the biggest advantage is that wtiting tests pushes me into the view of the user (caller) of the code. This helps to get it right the first time.
@victorserranobargues5 ай бұрын
Amazing I have learned many new things
@amorestperpe4 жыл бұрын
It would have been nice if you only had one camera. So it could take up the whole screen and be easier to see, and then do a split screen if he moved to like a podium... Just a suggestion, I'm also watching on my phone tho... But great vid.
@daniacedue55083 жыл бұрын
optimal, curious though of what uncovered things were on those cards, perhaps next time stretch the presentation duration if neccesary, give it a min and max limit instead of a fixed one , change presentation strategy if surpassed min limit (ex. accelerate, skip eamples.....just to cover those notions)
@juliakirshina42443 жыл бұрын
Sandro is my hero )
@DevTernity3 жыл бұрын
Indeed he is.
@HenrikVendelbo Жыл бұрын
It does! if you consider verification to be your only quality to optimise for.
@DodaGarcia3 жыл бұрын
I love TDD but this idea that TDD makes the application design itself never worked for me, all it did was leave me with a bunch of very stable methods and no idea how to best put them together. I had a lot more success by first planning the entities, then writing a round of pseudocode and only then using TDD to write the individual methods once I understand what the methods are. That pseudocode stage is where a lot of those decisions end up being made, it's where I find most redundancies and logic errors.
@pixelslate99792 жыл бұрын
Instead of using pseudocode you can use mocks to evolve your design.
@shrikantvashishtha66233 жыл бұрын
This talk is divine as it solves the problems which bugs almost everyone. Should you evolve design through TDD or you design first and complement it with TDD to evolve it further? Is evolutionary design sufficient or even possible without having any up front design? Sometimes when you are already deep dived in the code, it becomes difficult to look at holistic view. Moving bottom-up (TDD to design) is not that easy and always put a question mark in front of me. Things over here make a lot of sense. Thanks.
@davidtakac40889 ай бұрын
Incredible talk.
@user-tp8xp1hj8e2 жыл бұрын
interesting code, nice work with white board
@nikosc5 жыл бұрын
Superb talk...no words
@daniloapicella48693 жыл бұрын
Nice talk, a whiteboard and a pen seem to be even better than slides. I wish I would have watched this video when I started to use TDD. I reached the same conclusions the hard way in real projects when I started to encounter many problems, but I have never thought about the strategies I follow in the same way he did in the video. Only after two years of consistently adopting the TDD that I finally started to see clean and good designs and very simple and understandable tests, even for very complex features, and definitely not through just the pure classicist way. Also, I might say, many of the things he says about the second TDD approach, the outside-in I think he calls, result from Kent Beck's book, even if not that much explicit.
@jorgeolive96053 жыл бұрын
43:00 - He incidentally is jeopardizing the whole classicist school cargo cult. I absolutely agree that TDD won't give you a perfect architecture as some suggest - or that it will naturally move your system to industry proven architectectures for the matter - and you DO need to do some design upfront unless you want to spend an eternity rewriting and refactoring. Classicist might be good for StringCalculators and BankAccounts, but complex systems with lots of I/O dependecies? Yet to find a reasonable example on that style.
@drcl74292 жыл бұрын
I'm no expert on TDD but Bob Martin and Kent Beck certainly advocate lots of use of interfaces to allow for testing of single methods without dependencies like databases. It that mocking?
@elyesbenfarhat8595 жыл бұрын
fantastic talk!
@zHqqrdz4 жыл бұрын
Awesome talk. I wanted to add that one can avoid the problem of domain concepts mixing up together by using the Open Closed principle a bit more fiercely. So that in the example Sandro gave, the class "C" would not be modified and get bigger, it would instead be passed another class as some sort of "strategy" in its constructor, having the one used by the class "A" by default and the one used by class "D" as a new one. Those strategies should obviously be specific to their types of consumer.
@ManuelMontoyaRdz3 жыл бұрын
I can't see how TDD is related with the design, TDD is related with the generated code AFTER the Domain Driven Design is finished. It's impossible to capture the Domain with TDD.
@NarendraPathai3 жыл бұрын
Interesting. Can you please explain in detail?
@Jurigag2 жыл бұрын
@@NarendraPathai I think what he meant is - domain driven design should be done before writing any code - you go, talk to your domain expert and decide what entities, events etc you have, then you can code it in TDD manner and i agree with it. DDD is about how you design your product, how it's working etc, TDD is the clean way to implement what you designed. You can as well do DDD on on paper without any line of code.
@doichanvang5 жыл бұрын
I've learned a lot from you Sandro
@qasanov1985 Жыл бұрын
Perfect!. Thanks
@meamzcs3 жыл бұрын
This was great!
@vincentwhite76225 жыл бұрын
Sandro is so awesome
@FlaviusAspra3 жыл бұрын
To be fair, XP has TDD, yes, but it also has architectural Spikes.
@danielc42672 жыл бұрын
You can talk forever and I can listen forever :)
@FlaviusAspra2 жыл бұрын
TDD helps newbies not make great mistakes, but it also slows down great teams from making great designs.
@drcl74292 жыл бұрын
At 20 mins if you are having problems like that then it's because you are not following SRP. TDD is dependent on implementing SOLID.
@Tony-dp1rl10 ай бұрын
Not a lot of evidence here that TDD leads to good design. Interesting talk all the same, even if it is opinion.
@Pablo_IFАй бұрын
For God's sake! Let this man speak as much as he wants to!!!
@LittleSingerVivanshrivastava Жыл бұрын
Complete
@donwald34364 жыл бұрын
I've seen TDD work very well for hello world. I've never seen it work for a real oroject.
@gzoechi7 ай бұрын
It works perfect for algorithms or other rather complicated logic. It works less for rather boring code where just framework parts are wired up on backend or frontend. There tests can't add much value relative to the effort. TDD also works great for creating good APIs where the tests are the first user of the API. With TDD it's usually like with Agile. Most do it completely wrong and then complain that it doesn't work.
@donwald34367 ай бұрын
@@gzoechi Yea in the real world that's maybe 5% of the code base the rest is all glue and business rules.
@gzoechi7 ай бұрын
@@donwald3436 That really depends on what projects you work on. You are right. The glue code is often better tested using integration tests.