🚀 TDD, Where Did It All Go Wrong (Ian Cooper)

Notes I made during this presentation (just a dump, might be useful to some): - Test requirements, not low level - Test public API. Given when then - Test the exports from a module - Focus on higher-level - Test modules, not class - Refactoring is needed to see what is implementation and what is exports from module - Test behaviours - Think about your code as an api - Test the abstraction, not the implementation - Test are isolated and with shared fixture (to run quickly) - Red-green-refactor (go fast to working code) - No new tests during refactoring - Heavy coupling is the problem with all software - Thin public api  - Refactoring = changing internals - Patterns in the refactoring - If you're not really sure, write tests for implementation (delete the tests) - Not classes, behaviours - Don't isolate classes in testing - Private methods (these are implementation details)

I like this talk. What I learned: "Tests protect something. You want them to protect requirements, not implementation details. Thats why you delete tests that were only there to make it happen, but are not a result of a requirement"

21:00 where did it go wrong in TDD 22:30 recommended book 23:53 24:01 do not test implementation details, test behaviors 24:15 in classic modern TDD cycle , I will write a test before add that method, and that test will govern will that method succeeds or fails 24:30 the trigger to writing a test in TDD practice is essentially adding a method to a class, THAT IS THE WRONG THING! 24:50 THE TRIGGER in TDD for creating a new test is that you have requirement, you want to implement 26:03 testing the public API 26:13 what is the contract your software has with the world 26:28 (API) will not change rapidly 26:36 how you implement that requirement (contract, API) is unstable 26:44 what your software offers to consumers is the stable contract, that is what you should test 26:54 not HTTP API 28:46 SUT (system under test) is not a class

The problem comes from tools that do "CODE COVERAGE". Because of that metric, devs just end up testing their implementation so the chart that goes to the bosses and regulators is "oh look 99% code coverage of tests" when in practice it's doing absolutely nothing to improve the code.

This guy is speaking from hard earn't real-world experience. We need more engineers like him imparting their knowledge. Rather than 25 year olds who have real industry experience of 1.7 years and have already written 2 books.

15 years ago in my one of my first contract programming jobs (I was a late starter), Ian took me onto his team, assigned me a more experienced programmer as a mentor and told me to read Kent Beck's TDD book. It completely changed the way I approached programming. I'm immensely grateful of the time he took to teach me. Great guy.

I must confess that I've been mostly reluctant to the idea of TDD until just now. This is how TDD should have been "sold" or introduced from the beginning. Many people make TDD sound like if you have to know how the implementation of your methods is going to look like even before writing your first line of code. Outstanding talk.

35:15 "the unit in isolation is the test". This is HUGE! Need a quote from Beck's book.

I never understood the benefits of TDD until I watched this talk. This is gold. Ian Cooper seems to be about the only person making sense on this subject

You know this is a good video when you look at the like to dislike ratio with the maddening creaking going on through out the presentation

this talk is twice as effective after I have used TDD myself, helped me identify mistakes or incorrect ways of thinking a lot

I’ve had a hard time getting inte TDD and now I realize why. Great talk giving the philosophy and practice of TDD. I’ll read Kent Becks book right away and start testing behaviour. :)

Its always goes straight in the box of understanding when someone talk about actual philosophy of subject. He is talking with experience. Real Gold!!! THANX :-)

This is absolute gold and an eye opener.. thanks, thanks a million, thanks without end.

The best tech talk I've ever watched. Had a huge impact on my career.

Amazing lecture. Appreciate the hard-experience led talk and that is what gives it immense value, not the TDD/BDD but the higher understanding WHAT should be tested, i.e. the user behaviour. Fantastic, thank you.

'Think about your code as an api' was my biggest take away from using TDD process. That was my biggest pivot in the way I wrote code.

I was stuck for months on this question about TDD: "How are you supposed to write the tests for the methods before you know how the structure will look like?". This answers it completely.

Watched the original version of this talk a few years ago. This updated version is even better.

30:43 don't write tests to cover implementation details (because those change) 30:53 write tests only against stable contract of the API 31:02 Refactoring is the key step, which enables u to achieve the goal of separating between things like implementation details u don't need to test and the things you do need to test