Відео

"600 line service classes" - I would much rather read through a (cohesive) single 600 line class, than six abstracted 100 line classes

Good tidbits here, but much of this amounts to “don’t write bad or fragile tests” and “don’t do testing wrong,” which is about as helpful as “well, don’t write tightly coupled or fragile code.” The overarching narrative I just don’t think is particularly valuable.

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

Cute move to use "inclusion" to mean something other than its usual meaning of discriminating against straight white men.

long winded blow hard. geez I wonder if he ever gets anything done...

I think it's ironical that OO was invented to properly model domains and the real world and has been the main approach for doing that for decades, yet FP has been doing a better job of this for equally the same amount of time, but almost nobody uses it.

They didn't teach to do it fullscreen back in 60s

Great talk! Direct, honest and from experience! Thanks a lot Sandro!

Good talk. But the buzzing sound of the recording was almost unbearable. Please filter it out before uploading such a bad recording.

He's absolutely right about not testing one class or function in isolation. You test a functionality. This was always super obvious to me. But he spelled out the reasons in a little bit more detail whereas I kind of just implicitly felt it.

I hadn't expected any real world examples and you didn't disappoint me 😊 there's nothing practical in this presentation. Lots of claims and big words and absolutely no solutions to anything. That's why nobody is doing TDD. It's just impractical and a huge waste of time.

I literally treat this guy as my UNCLE! It's always a pleasure to listen to Uncle Bob - thanks for publishing this talk :)

There's no way you're slower with TDD. You can spend your time writing tests or you can spend your time fixing your crappy code and supporting your pissed off customers. Also, making changes rippling through tests sounds like bad design. AKA skill issue.

I applied a valid type by referring to the video. The code has become more readable. thank you

Excellent and insightful talk

Thought this was about Terry Davis, never mind.

Is there any project which is easily maintained by others without TDD. I don't think so. Robert clearly told that without TDD approach programmer will encounter lack of productivity within a day. I don't think you can ignore TDD easily unless the project is not already done by someone.

Footsteps sounds are very annoying.

60 mins of bullshit. Get a life 😂😂😂😂

The one of the best I ever seen

Amazing I have learned many new things

Thank you for sharing this fantastic presentation! I'm thoroughly intrigued by the scientific process involved in developing mental models for predicting the future. Dave adeptly linked this science with effective leadership and decision-making, which was truly impressive.

This is mind-blowing. Simple logic yet super powerful! This video should be viewed by millions! Dave should be teaching this at larger platforms. I would sacrifice a lot to work for such a true leader!

Maybe the reason I hate TDD so much is that I've always been on projects that are rapidly changing with poorly defined requirements. I very seldom encounter a project where I have good enough requirements to write tests BEFORE writing the code. I've also worked on projects where the leads are obsessed with code coverage and code smells, even though the code was still a bug ridden mess. I've spent more time writing tests, refactoring tests, debugging tests, and researching how to write tests than I ever did writing any of the code. The time and cost savings just wasn't there, and still isn't there. In my experience my untested code has been no more buggy than my tested code. You then have the massive bloat that comes along with making every single dependency in a class injectable (interface hell) so that it can be "easily testable", even though most of the dependencies you are injecting will NEVER need to have an alternative implementation during the lifetime of the code. You then have the problem of poorly written tests by inexperienced or low skilled developers, which will throw up false positives or falsely show that something is passing giving you a false sense of security.

I am waiting for a day that someone will convince me that TDD is a good way of wriring web FE code, especially dor frameworks. From my perapective it is a royal pain in the ass.

Ivar Jacobson

I have a vision in my head of having Alan speak to the IT leadership in my organization, but I always end up thinking it would have to look like that scene from Kubrick's "A Clockwork Orange" where they have the protagonist tied to a chair with devices that force him to keep his eyes open and watch the re-programming.

notes to self books: programmer anarchy, spike and stabilize, lean software development (all do away with tdd) test driven development by example kent beck refactoring by martin fowler refactoring to patterns by kerievesky ------ TLDR do not bake implementation details into tests as this makes refactoring difficult. refactoring is changing the internals of code not the public interface. the majority of tests must be unit tests as they are fast and automatic. 58:58

valid points, others not so valid. For instance, the use of `Either` results chained to a `fold` function seems an unnecessary overhead since you already have the conditional operator `when`. Besides being counterintuitive when reading from left to right, it makes it harder to read the code.

yeah this talk was a wonderful discovery.

There are not enough comments here - this was a well put together presentation! My question is: Can I use this technique in a Lisp-like language? I like the idea of thinking with algebraic types in order to get a birds' eye view, and wonder if I can apply this sort of thinking to languages lacking algebraic union types and compilers.

Very commendable presentation given it was held during an earthquake... Even the cameraman was holding it together (barely)

Thank you guys for recording it.

The sniffling m’kay. FFS

The suggestion to "just go read Kent Beck's Test-Driven Development: By Example" is amazing. GOAT suggestion. READ IT. It explains what the tests are *actually* for, and has full examples of how to use the process. And, surprise surprise, it's TOTALLY different than what my team was doing. Short summary: *start by writing tests from the client's perspective:* like `assert(Currency.dollars(5).times(2) == Currency.dollars(10))`. Then write the code to implement the tests. That's it! It's hard to write the tests? Refactor the code so they're easy to write. Writing tests is really annoying because there's lots of duplication? Refactor. Spending lots of time making elaborate mocks to test internals? Stop! You're doing it wrong. *Good tests == getting the right answer means your implementation is right.* THIS is what lets you refactor easily - if your refactored code passes all the tests, then it's right. In Gang of Four terms: do NOT peek behind the public facade! Just test the facade. Leave the details where they belong: as hidden details. It's not the details you care about: it's whether you get the right answer!

Scott Wlaschin is a god tier teacher !

If the trigger is a requirement, those come in very different shapes and flavors. "I need a software that makes some money for me online". What test would you start writing for that?. Prototype driven development is what really happens. All those other philosophies are only childs of particular situations that arise during development. Impossible to generalize as far as their followers usually try to do...

There is no way to do tests without establishing an interface between the testing system and the system being tested. This interface then has to be maintained. And then it becomes impossible to say if it is true that in most cases this extra maintenance cost is lower or higher than just manually testing the code for relevant cases or all the other intermediate uses of automated testing. Too many variables to explore. Is the same as asking is religion is good or bad. Who knows, but surely you would not want to say something that is likely to offend most religious people in front of an audience that you don't know...

And what were the user stories when IBM was writing DB2? All this "user stories" is crap that Web brought upon us. What's really needed is a smart guy who talks to the users and specs out the features. What you rally need is smart guys. And this is the crux of the issue: all this BS about respect, etc comes from an assumption that you have high quality people on your team. The kind of ppl who signed the Manifesto for Agile Development. Smart and passionate. The reality is far from it. you have to deal with mediocre lazy developers. Which is also doable but the Agile is not the way to make them deliver a decent product. You need a rigid process for that. You need to do it the way the Army does it. And I saw it done in 1990s

“The most effective organizations are learning organizations. Learning is The Work.” 38:35 Wish more orgs knew this and understood the truth of it. Fantastic talk

I'm a pathetic Kevin Henney fanboy and I understand that I **DO** have issues in this particular area... but I find myself wishing he actually did do that 50 hour version. ;)

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.

Promo sm

👍

6 years and we've not made any progress. And how many years since those books were written?

I was doing unit test for the last 2 weeks in my current job for the first time . I was mocking to dependecies of the class and also spying on the implemntation . I knew that I'm doing something wrong . Nice Lecture Now I understand how to go . what do you thing guy about mocking repositories with in Memory database for Unit test ?

What do you do if other devs complain that your refactorings "keep changing" the code they have to work with, directly or indirectly?

Oh how the world is broken in so many ways. It's astounding that there are still people that try to fix it. Especially knowing how hard it is and how everything and everyone is against you, against learning, against good...

That lanyard rubbing on the mic irritates me just about as much as doing TDD, TDD still wins. I do agree your tests should only test the behavior of a feature, not each method or function in your code.

Great stuff. Very insightful, thank you.