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

If we aren't writing tests against implementation details, are we really testing for correctness or are we essentially making assumptions of correctness?

Have I go the right end of the stick when I say...TDD is basically using almost E2E tests?

When Ian decide to go ZZ without a tophat

The biggest problem i have with tests being allowed to "touch" as many areas of the code as possible is that often times this may trigger false-positive errors, meaning a test fails in tests A, B and C each in different files and the underlying cause is actually the one under the file that's being directly targeted by C.

But the error might be unclear and so you might spend hours debugging files A and B needlessly and all just because you allowed the tests of these files to touch a function on another file. It's a bit of a problem when a bug in file C suddently causes every other test in every other file to fail as well, becomes a mess to figure out where the underlying problem is, so the underlying question becomes should these be considered separate modules to be tested in isolation from each other?

Going into production without having used TDD is squeaky bum time.

It’s funny how confused programmer get. Tests are really supposed to be testing if the black box give the right result, not how it does it. Let’s implement solid but then couple every test to the implementation details 😂

One of my favorite TDD talks ever! Thanks!

yeah still sounds useless to me

This talk is describing the original TDD concept or so called "classicist" school. There's also the new school of TDD often called "mockist". Both are opposing each other. And this talk is somewhat cliticizing the mockist approach. To get a full picture I'd recommend everyone to learn both concepts and decide for themselves which of the two could better fit their field. What works for microservice architecture might not always work for a mobile app.
What I don't understand from this talk and the classicist approach in general is the refactoring step, which seems completely optional to me. Why would you refactor after something is already working? Because of a smell? How would you know it's a smell? Because you've read smart books? (the majority does not read books).
Also a higher (than a class or function) level tests are more brittle. They do enable safe refactoring without changing the tests, but on the other hand require changing multiple tests should the business requirements change.
Likewise the mockist approach drives not only the implementation but also its design. One could say it's not TDD but DDD: Design Driven Development, as you have to come up with design before writing any unit test. Although you could write a higher level test if you like to, but I prefer writing it last to not have it hanging there red all the way through. And when the business requirement changes you often need to only change a test or two and write more for new units. You can also safely reuse your code, because even the smallest unit is tested.

TDD all sounds amazing ... until you ask a devotee to give you a link to a large code base that uses it successfully on GitHub, one that has very few Bugs or Issues reported (as would be the case if TDD worked). You will be waiting a long long time for their response.

Amen. For like 10 years i have this fight again and again that this IDE-driven approach of testing (tests focussed on methods) and especially TDD is horrible and responsible for the lack of adoption. It's tedious because while my public interface is pretty much set from minute one, i rewrite my class and method structure behind it constantly until it stabilizes. But that definition of what a unit is, was completely ruined by the industry, by IDE test-class generators and also by most TDD tutorials, which usually are so simple, that it looks like the method is the unit. If some of those tutorials would have added just another class to the unit and spoke about this issue, we would not have this mess today.
Also amen to the Gherkin-tool topic. I have not seen a single project in which the business actually cared (meaning read/write them) about those tests because most of them are not capable or interested to structure requirements precise enough even in natural language and most POs in large companies are just "managers managing external providers" anyways. So at the end, i still like to align automated acceptance tests with the customer, but i don't force my team to deal with stuff like Gherkin unless they really want to (as if that ever happens).
BTW: not complaining about Gherkin, Cucumber etc. Its a great idea, it works very well, but it's extremely hard to get the value out of it because almost every tool that tries to pull the business deeper into the development (BPEL, BPMN, BRM etc.) fails because at the end a developer has to do the job anyways. I love BPMN frameworks, but there are like 10 business analysts on the planet able to change an executable BPMN process without breaking it.

It's funny how one of the recommended videos below this one is that of Mike Ehrmantraut (Breaking Bad). LOL. Otherwise it was a good talk, I haven't even started any TDD but if was to get into it at least now I have some idea.

I made it half way through before all the sniffling and mic grinding drove me crazy.

I'm about halfway through TDD by example and listening to this talk again for probably the fifth time. TDD is extremely straightforward and incredibly deep at the same time. I'm still working on fully incorporating it in practice but it's SO much fun.

I think TDD should be said "tiddy."

I’m struggling to understand this because understanding it seems to rely on a particular understanding of what a “module” is.

In Ruby a module can be though of as (more or less) a bag of methods.

But from context it sounds like the speaker is referring to something different when he uses that term?

His ears lost theirs virginity long time ago...

I want to say, that this is one of the most helpful speeches on TDD or software development in general I have ever heard. Just one tiny thing...the background noice, I think it's the floor, drives me crazy.

Where did we go wrong? When we started making "units" small. Excellent presentation, with a lot to learn from it.

Ive tried to see the benefit of testing but ive failed, the payoff doesnt appear to be worth the cost so I just write code that works instead. Im working a long term project solo and im already climbing a mountain as it is without doubling my work with pointless tests for everything. Ive never spent more than a few minutes finding the source of issues in a debugger so ive never been in a situation were I thought, "i wish i had tests". I guess I can see the value if you are a company with many people working on the same code, coming and going etc, its kind of an anti idiot protection, but theres just no value in it for me personally.

Tests are just more code, its subject to same limitations of knowledge, you cant test for what you dont know, its a false sense of security. Im confident in my code, writing more code(tests) wont make me more confident.

great talk, horrible audio... it's like someone's groping the recording microphone the entire time... shame about the audio... but, great talk

somebody get this guy a tissue

I believe that your refactoring should be based on required behavior, laziness of a developer or practical readability of your code. Two later ones are kind of required tests and to some extent can be checked by tools but not always. In general most refactoring imo should be test driven for us to really know why we do it and can ensure it was actually done and that change is not removed later (though it can be replaced with a better implementation). Refactoring sometimes may be the place where you may want to write normal TDD test and not BDD to test your implementation detail. But in probably 99% of such cases you can come up with some behavior driven test too.

DD programming is the way to go

I particularly appreciated the bit about using unit tests to aid in building implementation details and then deleting them. I've got quite a few of those to hunt down and it makes sense, as these are often superseded by higher level tests that focus on the public interface.

Thats why every SE worth his salt is avoiding teams claiming to do TDD … it’s usually bunch of mislead puritans that just fixate on testing every minute part of implementation making any refactoring / feature adding unbearable.

Short version: If your tests will be broken by refactoring, you've written bad tests (generally speaking -- there's probably couple of unavoidable exceptions).

This what he states: to test the behaviour and use the ports of the actual implementation, sounds like a familiar test environment and test behavior how you do it in hardware development (FPGA, with VHDL), when you for example test the DUT with the testbench.
It sounds about right what he os saying and stating.m

I generally agree. But I want to add that TDD is terrible when you have COTS applications, and in my case embedded system applications. As there's no (or very little) public interfaces, and what we need to test is highly technical -- depends on edge triggers, timing etc. And your test code in order to insert data or get the result soon becomes more complex than your functions.

But we do test the end product (like most real engineers do) heavily.
I am mostly into order picking systems, and we actually test scenarios like: "what happens when a power outage happens" because those pills on the conveyor will not disappear they are there and need to be delivered to the person at the counter of the pharmacy.

Ironically our hardware is better equipped than the business software using it!
Because I register in dedicated non-volatile RAM what is in transit. So when the power comes back on, I know where the package came from, what it is (even though we don't care but we could inform the business software as they don't seem to know), where it needs to go and we even have what is called "triple redundancy" because memory can get corrupted. So you need a second copy and a tie breaker.

So we design with actual failure scenarios in mind and I don't see that in business software. I don't see software developers explore the edge cases. Like for example a transaction.
Imagine you have $300 credit on a $35.000 account. And you have two transactions simultaneously how do you order them? How do you guarantee the are done in the right order?
For example a $35.300 transaction would cause an over draw and you need to pay a fine. Whilst that $300 would have countered it. So in a given time frame you need to order those where first the credits are done and then the debits. At banking we think about these things but I hardly hear developers explore these edge case - also product owners and architects not anymore!

Things go wrong when you let autistic people with OCD make decisions for everyone else.

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.

After 16 years as an IT consultant, I've NEVER seen a fully or even partially working TDD strategy. If TDD actually worked, everybody would use it, and it would largely work. But most people don't use it, and the ones that do get it wrong. My conclusion is thus that TDD doesn't work, and never did.

Nice speech, thank you
An interesting viewpoint on TDD and i totally agree about how it slows down whole development process (by wrong testing implementation)

I really wish that guy sitting next to the microphone would stop making balloon animals.

mvp for c# means: answers questions on ms forums and later they give you the title "mvp" and you get to talk about programming in an authoritative manner.
it is an absolutely worthless title that is touted and waved around by worthless people as if it is an MIT diploma.

Fantastic talk. But that crunching sound is so annoying. Is it the person behind the camera?

For me this is one of the most forgotten golden rules in the industry and it's costing billions.

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

My man's fought so hard to keep that snot in. Respect

The one thing I'm missing in this video is the fact that the proposed BDD approach would have as a consequence that the focus of management on test coverage metrics should be abandoned because I don't see how one can apply BDD and still get a high percentage on code coverage. Unfortunately test coverage percentage has become a very popular yet often misleading metric for quality so it will take a lot to convince companies. Mentioning it would however be a good start.

K.

Great talk. It mostly reflects the philosophy we used at the project I was working on in 2017.