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

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.

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

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

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

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

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

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.

pointed out the exact point of Concern rather than beating the bush Felt very Clear and Empowered in the end Thanks Again Loved it

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

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

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

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

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.

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

Two more hours of this would’ve been great!

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

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.

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

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

The second half of this video is simply brilliant

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

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.

Amazing I have learned many new things

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.

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)

Sandro is my hero )

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

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.

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.

Incredible talk.

interesting code, nice work with white board

Superb talk...no words

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.

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.

fantastic talk!

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.

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.

I've learned a lot from you Sandro

Perfect!. Thanks

This was great!

Sandro is so awesome

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

You can talk forever and I can listen forever :)

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

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.

Not a lot of evidence here that TDD leads to good design. Interesting talk all the same, even if it is opinion.

For God's sake! Let this man speak as much as he wants to!!!

Complete

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

Or just use function programming wtf?