Brilliant talk, quite a unique one in that category. I started to nurture TDD back in 2010, applied in a project in 2016, and afterwards somehow lost track. Started it again in 2022, I just love it now.
to be honest, I think TDD just wasting time, but this talk makes me start to like TDD. The benefit of "documenting of my todo list after lunch" seems a great benefit.
One quote about TDD that I love went something along the lines of "I've never heard of someone who really tried TDD and thought Nah, this is a waste of time. I'm going back to my old ways." Learning it is like learning how to walk. You'll probably never crawl anywhere again😅
Happens to gamedevs all the time, because our requirements are fuzzy emotional judgements about what "fun" means, which means we can only meaningfully test implementations without going farther up the abstraction levels than most mainstream test advocates would want us to do. This results in TDD advocates telling us we're doing it wrong, so we throw our hands up and go "TDD is impossible for gamedev" and stop doing it. It takes experience and effort to overcome these hurdles and figure out *what* to test in a video game and many gamedevs do not get that far or if they do, don't get enough value from it to continue.
Great talk. When he started talking about requirements at 3:38 I was like "But TDD is great at codifying requirements!!" and then he proceeded to say exactly that.
I stumble upon this video when I search "golang mock database" OK, I'll close this video browser tab and continue to code instead of worrying how to mock my mongo repository
this talk looks like a rendition of this 2017 talk: th-cam.com/video/tsNoYv0P2O0/w-d-xo.html whether this is by coincidence or the speaker took inspiration from it, I do not know
Very cool! I was surprised though, how non-idiomatic the variable naming was. I would think that all the presentations at gophercons would stick to idiomatic go.
I love how he says "these are not my problems when I code". He is absolutely correct, his code is everyone else's problem ! Which is the whole point of Testing. He wants to get shit done. As opposed to get shit done right.
@@babgab Yes, SOMETIMES. But the problem is there are too many people who can not bother or even are able to create clean code and ALWAYS write garbage code.
That face of TDD evangelists when writing tests will be substituted by the much more efficient and more exhaustive automatic generation process through formal methods. Can't wait.
These people are not able to write a simple line of code to test. Do you think that they can write a formal process to test that everything is okay. My experience with formal language was pretty good, but most of people are not able to follow a formal method.
I bet for that after several months from now, this same guy, that he just discoved that writing tests make him know what the next step is, to make sh**t done? will give another funny talk about how tests make him modify his code aggressively to meet the new requirements without worrying about braking other codes because tests are in his back and let him know soon, and he will agree that tests increase confidence in modifying code (NB. not refactoring: because refactoring by definition don't change code behaviour but design).
I really wonder. Why do you guys always worry about changing code that obviously already works? If requirements change, obviously it is not always the best idea to look at tests that were for the old ones.
@@SarahAndreaRoycesChannel there are two kind of maintenance. *Refactoring* *New requirements* From ur question seems like u don't do first one. And what about u break old code while implementing new requirements?
Nah, you didn't understand his test function. It was test scenario, one test function with different inputs and results. You just proven his point about TDD community, shaming and following "rules" without thinking what is the point of the test.
I think you didn't understood it was one big stand-up comedy and sarcasm. He even put there Kent Beck, father of TDD to mock TDD itself with his words...
I put this on my list of greates talks ever - and all in under 14 minutes, first class job!
That explains why the talks are the "greates"
Who are you and why are you HILARIOUS???
BDD, Bug Driven Development. New Favourite Thing!
"if there's a bug, I solve the bug" 😂😂😂
This is one of the most entertaining dev talks I’ve seen! And informative
TDD is like testing a car engine without even making it. But CDT(concept/requirement driven development) is more likely to be logical.
Brilliant talk, quite a unique one in that category. I started to nurture TDD back in 2010, applied in a project in 2016, and afterwards somehow lost track. Started it again in 2022, I just love it now.
to be honest, I think TDD just wasting time, but this talk makes me start to like TDD. The benefit of "documenting of my todo list after lunch" seems a great benefit.
It's probably you never saw real TDD. Try Uncle Bob's talk "TDD with Kotlin" based on "Writing Stack example" or "Writing factors example".
One quote about TDD that I love went something along the lines of "I've never heard of someone who really tried TDD and thought Nah, this is a waste of time. I'm going back to my old ways." Learning it is like learning how to walk. You'll probably never crawl anywhere again😅
Happens to gamedevs all the time, because our requirements are fuzzy emotional judgements about what "fun" means, which means we can only meaningfully test implementations without going farther up the abstraction levels than most mainstream test advocates would want us to do. This results in TDD advocates telling us we're doing it wrong, so we throw our hands up and go "TDD is impossible for gamedev" and stop doing it. It takes experience and effort to overcome these hurdles and figure out *what* to test in a video game and many gamedevs do not get that far or if they do, don't get enough value from it to continue.
That's one helluva talk! It's always great to insert humor in tech talks, never a dull moment.
Great talk. When he started talking about requirements at 3:38 I was like "But TDD is great at codifying requirements!!" and then he proceeded to say exactly that.
Entertaining talk! I believe Uncle Bob himself describes TDD as “A way to incrementally derive solutions to problems”
Best talk ever!
What a mad lad I love it!
Amazing talk, would love to see more from him!
Fantastic talk!
One of the best talks I've ever seen and informational as well!
enjoyed the talk. nice angle.
Actually, he did a TDD. But he explaining usage from another perspective which is I think it's good and entertaining :-)
What a great talk 😁
I have been doing bug driven development 😄😄😄
this guys is smart he know how human works not only machines.
Bug driven Development (BDD)
Going to use this from now on as an excuse when I don't write tests
Awesome! very capturing
best Go talk I've seen. love this dude
Without a doubt, best talk ever
Bravo!
This is what i've been searching for so long to convince people. This is simply great!
I stumble upon this video when I search "golang mock database"
OK, I'll close this video browser tab and continue to code instead of worrying how to mock my mongo repository
That was a great talk!!!
Thanks!
Loved this awesome information
this talk looks like a rendition of this 2017 talk: th-cam.com/video/tsNoYv0P2O0/w-d-xo.html
whether this is by coincidence or the speaker took inspiration from it, I do not know
One of the best talks about TDD
Funny thing is, Kent Beck is one of the "fathers" of TDD xD
bye bye TDD
BDD is the future.
Very cool! I was surprised though, how non-idiomatic the variable naming was. I would think that all the presentations at gophercons would stick to idiomatic go.
awesome audience
I love how he says "these are not my problems when I code".
He is absolutely correct, his code is everyone else's problem ! Which is the whole point of Testing.
He wants to get shit done. As opposed to get shit done right.
Sometimes getting shit done is more important than getting shit done right
@@babgab Yes, SOMETIMES. But the problem is there are too many people who can not bother or even are able to create clean code and ALWAYS write garbage code.
This video triggers my phone's Google Assistant around 3:46. Good job!
How to be a brogrammer 101
Brilliant!
OG
Awesome talk...
👏👏👏
That face of TDD evangelists when writing tests will be substituted by the much more efficient and more exhaustive automatic generation process through formal methods. Can't wait.
These people are not able to write a simple line of code to test. Do you think that they can write a formal process to test that everything is okay. My experience with formal language was pretty good, but most of people are not able to follow a formal method.
1:55 😂
I have problems to understand TDD and I watched a lot of videos about it. But this video works for me. Thanks Chew Choon Keat.
I bet for that after several months from now, this same guy, that he just discoved that writing tests make him know what the next step is, to make sh**t done? will give another funny talk about how tests make him modify his code aggressively to meet the new requirements without worrying about braking other codes because tests are in his back and let him know soon, and he will agree that tests increase confidence in modifying code (NB. not refactoring: because refactoring by definition don't change code behaviour but design).
I think he was largely joking about testing being bad.
He knows what regression test means.
I really wonder. Why do you guys always worry about changing code that obviously already works? If requirements change, obviously it is not always the best idea to look at tests that were for the old ones.
Thing is these newbies don't understand even SDLC completely...
They just want to make sh*t done with out thinking about maintenance.
@@SarahAndreaRoycesChannel there are two kind of maintenance.
*Refactoring*
*New requirements*
From ur question seems like u don't do first one.
And what about u break old code while implementing new requirements?
great :D
So TDD is a glorified todo-list?
I understand that he didn't understand TDD. Having "if" in the test is an obvious evidence.
Nah, you didn't understand his test function. It was test scenario, one test function with different inputs and results. You just proven his point about TDD community, shaming and following "rules" without thinking what is the point of the test.
This talk is sad and childish. Is 2020, we should be discussing how improve TDD, not if we should use it or not.
This talk is about getting into TDD, there are other talks about improving it.
I think you didn't understood it was one big stand-up comedy and sarcasm. He even put there Kent Beck, father of TDD to mock TDD itself with his words...
"I don't like TDD community, I come from Rails community" - Stopped watching right away...
You should give him another chance. He does comes around to TDD, and is pretty funny while doing so.
@@fabioteixeira868 I have such a low threshold for BS that I sometimes miss the good stuff. Thanks! :)
One of the best talks about TDD