@jaymandell6034
I wish they would show the screen as he's writing/talking
@camilohernandezruiz2776
I just replicated the example in Dart. I learned a couple of things:
1. You must have an intermediate level of using the language.
2. Every testing environment is pretty much the same. Still, the conventions used by the Dart test library and the different Exceptions-related objects are different than those used in Jest, so you gotta know them all as well.
3. The KISS principle is the most important one. Don't advance too much further, every time you write something, run the tests. Keep refactoring and running at the same time until the all tests pass. This is the moment when you use all your brain.
I also collected every tip/rule Uncle Bob explained about TDD in this video:
1. You are not allowed to write any production code until you have first written a test that fails because the production code doesn't exist.
2. You are not allowed to write any more of a unit test than is sufficient to fail - and not compiling is failing.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
4. Engage as few brain cells as possible, you will need them later. Keep it simple! (KISS) Don't do too much too fast.
5. Try to avoid the core (the golden behavior) of the problem until it is unavoidable. Save the most important feature of it for as long as possible.
6. If you think some code you just wrote is a wrong solution... prove it! Put it to a test.
7. You are not allowed to make the production code more specific than the tests. The tests and the production code must move in opposite directions.
Every new test you add makes the test code more specific, more constrained. Everything you do to the production code must make it more general.
@aimafirm
With all the comments everywhere on youtube, it can't possibly be that hard to realize that one should show the code being written and not the presenter.
@FranciscoMNeto
Beautiful lecture, abysmal editing.
@unitycoin_original
0:00 Opening. 0:51 Honest Estimates / What is the chemical formula of water? 7:16 Selection, Secuence and Interaction / No innovations have been made in the software for decades. 13:48 The Hardware has gone crazy!: comparison between the innovation level of hardware and software today. 17:33 You to say "No". 21:40 Test-Driven Development / TDD rules. 36:14 Our code is a document / Double entry Bookkeeping. 40:22 About inheritance / Mutation Testing. 43:48 Demo of Test-Driven Development. 1:12:23 Some tips to learn and practice Test-Driven Development. 1:15:03 Questions and Answers.
@jamesnewton6139
to Uncle Bob: amazing lecture, these principles are absolutely required, to produce good code. however, to make this a 1000 times better, if you have the power and see this, get the video editor to re-edit and show the code. Extremely frustrating to watch you talk about details of code and write something, but nobody can actually see it.
@devsquaredTV
dear uncle bob, youve been an amazing source of happiness since i discovered you last week
@HeikkiKetoharju
This was the best demonstration of TDD I've seen to this day. Really inspiring!
@JavierRuizGonzalez
Don't you love when a lecturer shows that they are able to actually put the theory in practice? Also, you can feel how knowledgeable is a guy by counting the number of times he mentions other colleagues. Thanks for these sessions, to the organizers and to the editors!
@wolverine9632
There's so much invaluable information in these lectures. Test-driven development was a completely foreign idea to me, but interestingly, when it was first mentioned in Lesson 3, my brain clicked and I sort of saw it inside my mind. I was thinking of the fact that I always have introduced new structs/classes by definition first, followed by implementation. My reasoning was that, "If I design the blueprint first, it will be easier to implement." But I realized this is backwards from what it should be. I should attempt to create an instance of the object, and when that fails, then and only then should I add a declaration for the class. Now I add a call to the non-existent member function, and only after it fails to compile do I implement the function. This way I will automatically develop the class interface in the way that makes the most sense, adding everything as needed, rather than creating an entire implementation before realizing that interacting with it is a real chore. Turns out, this isn't exactly what Uncle Bob meant, but it's well on the right track.
@GerbenWijnja
I like to think of this flow of test driven development as continuously proving that there are bugs. Prove that's there's a bug (a.k.a. missing or broken feature) with a test, then fix it. Then prove another bug, and fix it. Until you can't think of any other bugs.
@headoverbars8750
Man... I struggled to wrap my head around this discipline until the demonstration. I have seen many demos but non clicked like this. Game changing Book/Series the demonstration for TDD was icing.
@yapayzeka
this dude is legend
@TheInimicus
I watched this lessons 3 times now, and everytime I learn something new.
@CPalanysamy
This video made all the difference when it comes to understand TDD. Thank you uncle Bob
@moganmark
An absolute legend, thank you for posting
@polomarco8773
21:05 Fortunately I haven't been put in this situation yet, but this is a really great tip. I never realized "would you at least try [to make the deadline]?" has a sneaky double meaning to it
@fluffydeveloper
44:15 Bob: singing The subtitle: don't eat it eat it eat you know
@milanmidzovic6841
I don't know anything about programming but I enjoy his lectures.
@wolverine9632