🚀 Does TDD Really Lead to Good Design? (Sandro Mancuso)

[@RmaxTwice]

What an unbelievable amount of raw concentrated developer experience directly distilled into our brains. Bravo

[@detaaditya6237]

Finally a clear image of how TDD is applied in real world problems. Thanks man, that was a great explanation!

[@wedesoft]

Finally a talk with an answer to the question where to use mocks and how to choose your units.

[@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.

[@murates]

Absolutely great talk! First time I see someone that can go into such great detail and address the real issues as opposed to just giving some basic principles without considering the implications in a real world scenarios

[@RoamingAdhocrat]

Just to say I really appreciate this camera setup - the fixed view showing the whiteboard clearly, and the second view of the presenter.

[@edgeeffect]

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.

[@zHqqrdz]

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.

[@kevinfleischer2049]

Check out "Improving your Test Driven Development in 45 minutes - Jakub Nabrdalik" . I found it good too. kzbin.info/www/bejne/aKeooH9pftean9k

[@MohamedCherifBOUCHELAGHEMdz23]

@@kevinfleischer2049 Thank you, I'm curious to see how he used C4 model!

[@wealcome_company]

Check out this one : vimeo.com/68375232. best ever

[@bluebottle4]

I agree. I could have listened to this guy for much longer. But nice bait, asking for similar quality material ;)

[@dardanbekteshi3177]

kzbin.info/www/bejne/e4uTZphterKCgq8 here's another TDD talk of a very high caliber. Enjoy :)

[@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

[@eduardocosta9078]

Amazing talk in the classic old school style, a white board, a pen and the ideas bubbling up in the mind! Congrats.

[@ruixue6955]

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

[@nikitakoselev4179]

That is a mind blowing actually. One of the best talks I have seen in 2021.

[@hartmannsson]

Two more hours of this would’ve been great!

[@Chemaclass]

This talk is a must-watch for all devs! Thank you!

[@dimitriostsobanopoulos7]

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_zapata]

25 years. That's a long time. :D does it finally get easier after that long. Congratz man.

[@dimitriostsobanopoulos7]

@@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_zapata]

@@dimitriostsobanopoulos7 that's brilliant. It totally makes sense.

[@youssefmourchid9149]

thank you Sandro for demystifying this subject, it's a pragmatic way to practice TDD, brilliant

[@matthieucneude5761]

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.

[@johanrg70]

@@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.

[@chauchau0825]

I am glad he spent entire talk demonstrating TDD does not lead to good design. Good Design Decision does.

[@abduljeelani4040]

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 ..:)

[@gzoechi]

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.

[@rkgrachel]

Three years ago, still GREAT talk! Thanks a lot.

[@aalbero]

The second half of this video is simply brilliant

[@lzszl]

Love the Talks, the music at the end needs the gain turned down, blew out my headphones

[@jayoolong279]

Such a good talk, I am sad that there wasn't enough time!!

[@F2H16]

Incredible, it's all raw experience that has been put into this talk. Hats off 👍👍👌👌

[@daniloapicella4869]

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.

[@zHqqrdz]

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.

[@amorestperpe]

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.

[@shrikantvashishtha6623]

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.

[@daniacedue5508]

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)

[@HenrikVendelbo]

It does! if you consider verification to be your only quality to optimise for.

[@juliakirshina4244]

Sandro is my hero )

[@DevTernity]

Indeed he is.

[@DodaGarcia]

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.

[@pixelslate9979]

Instead of using pseudocode you can use mocks to evolve your design.

[@victorserranobargues]

Amazing I have learned many new things

[@ДмитрийК-н7и]

interesting code, nice work with white board

[@davidtakac4088]

Incredible talk.

[@jorgeolive9605]

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.

[@drcl7429]

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?

[@nikosc]

Superb talk...no words

[@vincentwhite7622]

Sandro is so awesome

[@doichanvang]

I've learned a lot from you Sandro

[@elyesbenfarhat859]

fantastic talk!

[@ManuelMontoyaRdz]

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.

[@NarendraPathai]

Interesting. Can you please explain in detail?

[@Jurigag]

@@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.

[@qasanov1985]

Perfect!. Thanks

[@danielc4267]

You can talk forever and I can listen forever :)

[@meamzcs]

This was great!

[@FlaviusAspra]

To be fair, XP has TDD, yes, but it also has architectural Spikes.

[@FlaviusAspra]

TDD helps newbies not make great mistakes, but it also slows down great teams from making great designs.

[@drcl7429]

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-dp1rl]

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

[@donwald3436]

I've seen TDD work very well for hello world. I've never seen it work for a real oroject.

[@gzoechi]

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.

[@donwald3436]

@@gzoechi Yea in the real world that's maybe 5% of the code base the rest is all glue and business rules.

[@gzoechi]

@@donwald3436 That really depends on what projects you work on. You are right. The glue code is often better tested using integration tests.