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.
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.
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.
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.
@@Sammysapphira you have a reading comprehension problem. I said you can spend time debugging code like a noob, or you can write tests like an adult and not waste time debugging.
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.
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.
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.
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.
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!
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
@@nuvotion-live Simon Brown C4 stuff and everything by Coplien. Anything that's not TDD bs push. But thing is, you never have a team of really smart capable ppl, except in rare cases like some startup or Google Go lang team. U need to be able to make average, often mediocre ppl deliver decent product. And it's done with leadership, mentoring, discipline. I saw it done at IBM. The army like approach.
@@nuvotion-live the whole point is that there is no single magic process. the process is established by the senior people on the team, just like a lead surgeon set the process for his team. Read Fred Brooks, he wrote a lot about it. Same goes for the coding standards. No BS like TDD or some other crap like that.
@avsync-live anything published before 2010 should work if uou have real professionals, as they would be capable to choose approach and adjust it to needs. As one ex-M$ project manager wrote, all software development books describe dancing around developers while they wrote code. And yes, it does much more sense if all you've got is mediocrity.
@@alexanderpodkopaev6691 if uou have real professionals, And this is the key! What the last 10 years have been is an attempt to make mediocre ppl deliver something via a process rooted in maximizing FUN for those mediocrities.
“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.
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 ?
@@edgeeffect yes! Exactly! Or there's too much to test manually because there's not (enough) automated testing. Even though you have improved the code a lot and fixed some really bad design, allowing faster and safer development in the near future.
That's when one looks for another team/company/project. If these best practices are for, whatever valid reason, seen like that, the one is seen as an unfit cog in the organization. I have seen similar things happen in healthcare systems in eu in conjunction with php and .net
If the changes are a lot and devs can't follow the thought process, do pair programming or even mob programming. Integrate them in the process so they can digest all the steps, not just the end result.
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.
Wow! I formulated my own scratch hacking method (for script writing) and tought it to my pupils, and Phase 1 and 2 sounds very similar to the Q'n'D phase of and the refactor phase of TDD. Thank you! That was interesting indeed..
