"for this video, i'll be calling test driven development 'TDD' for brevity" *procedes to use 'TDD' once in the next sentence and 'Test Driven Development' in the rest of the video* lol
Alright you got me! thanks for watching the whole video. Saying TDD takes about the same amount of time as Test Driven Development, guess I wrote TDD in the script but just read out the whole words when reading it.
Most important aspect of testing is to ensure you not only test for success, but also test for failure. Verify things that they're not supposed to be able to do.
I completely agree. A bunch of my code in a new project I’m working on is lacking tests and it really shows! It’s just a proof of concept to test some ideas but will need to add tests as we iron out features.
@@NickMaltbie relatedly, it's also really important to ensure that your tests actually fail before you implement the fix. otherwise your test probably has a bug and isn't testing what it's supposed to test
I've been a tech artist in games for 22 years (started as an animator, but quickly started writing my own tools, and in a couple years was only coding tools and systems all day). I discovered TDD in flame wars online back around 2012. It was very contentious back then, and I'm glad these days people mostly see the goodness of it. Something about it felt interesting. I care hard about rock solid code that just keeps working for years, and was pretty good at having low bug counts, but wanted no bugs. I decided to read Kent Beck's book (TDD: By Example), and then decided to do it 100% for 6 months, to really give it a fair shake. I'm more of a library developer anyway - I build the library needed for a tool, and then use it to make the tool, so it's usually 80-90% library, 10-20% tool - and it's really easy to test pure library stuff, rather than tools with their UIs. Anyway, I realized 2 years later - still doing TDD on everything - about 24 libraries at that point, serving dozens of tools - that I'd not had a single [known] bug in 2 years. Everything just worked, always. In fact, now, 12 years later, I still haven't had a known bug in production. Games, especially tech art, is riddled with bugs. In contrast, I almost can't open a piece of random tech art code at any company without pretty quickly finding a bug. They're everywhere. I have so many thoughts on TDD, and even gave a long talk with all my epiphanies and discoveries from TDD. Simultaneously, I was also getting into functional programming in Haskell, and still love it. Both it and TDD changed how I code in fundamental ways, and I noticed parallels. They both really focus on separation of concerns, and both push you toward the functional core/imperative shell paradigm (good talk on this from way back: ua-cam.com/video/yTkzNHF6rMs/v-deo.html), which is a very robust way of building code. I left that company where I learned TDD, and found out they were still using all of my tools 5 years later, and still nothing had ever broken. Still no found bugs, even in my half-decade absence.
It's important to make good distinctions about the terms being used otherwise beginners would try to use "TDD" and be frustrated as it doesn't work as expected, it doesn't fit with what it is being told by other devs, or takes too much time. Some limitations of the original TDD (and most of the definitions found online) is that TDD is not fit for non-deterministic systems and for graphical applications (games tend to be both of those). I said this because the video doesn't disclose which definition of TDD (i.e, from what author) is using. The first TDD definition (the one popularized by Kent Beck) and even the one you find of wikipedia, doesn't make mention of requirements (those are more for BDD and acceptance tests) and this video makes omission of TWO very important aspects of TDD: the refactoring step, and the possibility of going in small steps for developing. Also, I have to check the test written in this video, it peaks my curiosity since I'm pretty sure there must be a mathematical way to prove that the fix will work with any angle and with a good variety of shapes for the player object instead of just using fixed angles as test cases. Full disclosure, you don't need to implement the "mathematical way" for testing features because one, they tend to be more complex to understand and maintain, and two, they add a barrier for collaboration, so the fixed angles are good enough. If the bug is reported again for cases not covered, then it may be worth exploring the "mathematical way" tho
Tdd is great if you're working on bigger projects, but on smaller projects it may make them take longer for not much gain. Also note that you may want to run a cycle of random or sweep tests, which may catch some edge cases you didn't know about.
This is great! Writing tests is an extremely useful and often overlooked tool that developers have. I think they can be easy to ignore early on in favor of manual testing, but in the long run they are invaluable. imo I'd go as far as saying that if a feature doesn't have a test, it isn't a feature, it's a helpful bug.
Fun thing is that the corner bug you mentioned in the first half of the video is a well-known glitch in SM64 that allows things like wall clips and other weird behavior. It's cool that even without knowing about the code on Sm64 specifically, you ended up at the same problem that nintendo did, meaning you both discovered the same way of programming movement
Thanks for watching the video and leaving a comment! I didn’t know the jittery sliding at corners was a bug in older games too, I know Portal 2 and source engine have that problem as well leading to fun infinitely velocity glitches. Bouncing and sliding movement methodology is a well accepted way of having smooth movement over collision surfaces.
tdd is great for huge collaborative projects where you cannot afford to have a tester test every single commit, for smaller projects the results are diminishing or it can even hamper development
Trouble is now we have satellites & drones, you can just compare photos and track where all the trees are moving to... Don't even need a human to analyse the imagery. And while I haven't heard of anyone doing this, well, I wouldn't hear of it now would I, but I'd be surprised if it's not happening.
The problem I've always found with test driven development was actually in the first part of your list - defining the requirements. It is often difficult to know exactly what you SHOULD be testing for before you've actually written the code. The process of coding is largely a process of building your understanding of the problem space. Tests prior to that process often do not reflect what's actually needed. Not always obviously, and usually you can lay out the basics, but edge cases are certainly not easily predicted and they tend to be where tests become most useful.
As a software developer, TDD is the only way to develop software. I wouldn't write anything that will actually be used without tests. Testing is not optional. All software that's being used will be tested. If you don't automate the tests, your users will test it for you. You know who hates testing your software more than you? Your users. You know who is totally okay with testing your software? The test runner. It's very satisfying to have a whole application powering half a business run its test-suite containing 1000s of tests in a few seconds. A common complaint I see is that writing tests slows you down: In no way is developing apps with TDD slower. It might be a bit slower at start (especially if you're unexperienced in writing tests), but once you're experienced with writing tests and the application starts to become bigger, these tests will help a lot. Additionally, between all applications I've seen, there's a CLEAR difference between applications that applied TDD and did not: The TDD app will always have a lot less bugs. If you open our error notifier for all our apps, there will be a huge difference in amount of errors between the tested and untested applications. Additionally, the types of errors differ widely. While the TDD apps only fail in "weird ways" (unexpected scenarios, weird requests, external services with unexpected outputs), the untested applications will overwhelmingly fail in stupid ways like missing methods, NULLs, typos, etc. Only by looking at the incoming errors, you can quickly identify what app was tested and what wasn't. The problems with not using TDD amplify once you add multiple people to the same codebase. Once there's multiple people involved, you have no longer that mental image of all parts involved, because some parts are not written by you. (Time does the same thing; You will not remember the details of anything you've written some time ago) You'll play an endless game of whack-a-mole of fixing bugs while breaking other parts of the code and you'll end up being afraid of changing anything up to the point of just not wanting to work on the application anymore. You'll be desperate for a rewrite, because the current thing has become a steaming pile of hot garbage. If you're granted permission for a rewrite, you'll just create the same steaming pile of hot garbage.
@@gamebuster800 To my understanding TDD is specifically coding where you write the tests first prior to solving the problem, right? I don't think it is a rejection of tests entirely. Writing software without testing sounds like hell lol.
"for this video, i'll be calling test driven development 'TDD' for brevity" *procedes to use 'TDD' once in the next sentence and 'Test Driven Development' in the rest of the video* lol
Alright you got me! thanks for watching the whole video.
Saying TDD takes about the same amount of time as Test Driven Development, guess I wrote TDD in the script but just read out the whole words when reading it.
Most important aspect of testing is to ensure you not only test for success, but also test for failure. Verify things that they're not supposed to be able to do.
I completely agree. A bunch of my code in a new project I’m working on is lacking tests and it really shows! It’s just a proof of concept to test some ideas but will need to add tests as we iron out features.
@@NickMaltbie relatedly, it's also really important to ensure that your tests actually fail before you implement the fix. otherwise your test probably has a bug and isn't testing what it's supposed to test
I've been a tech artist in games for 22 years (started as an animator, but quickly started writing my own tools, and in a couple years was only coding tools and systems all day). I discovered TDD in flame wars online back around 2012. It was very contentious back then, and I'm glad these days people mostly see the goodness of it. Something about it felt interesting. I care hard about rock solid code that just keeps working for years, and was pretty good at having low bug counts, but wanted no bugs. I decided to read Kent Beck's book (TDD: By Example), and then decided to do it 100% for 6 months, to really give it a fair shake. I'm more of a library developer anyway - I build the library needed for a tool, and then use it to make the tool, so it's usually 80-90% library, 10-20% tool - and it's really easy to test pure library stuff, rather than tools with their UIs. Anyway, I realized 2 years later - still doing TDD on everything - about 24 libraries at that point, serving dozens of tools - that I'd not had a single [known] bug in 2 years. Everything just worked, always. In fact, now, 12 years later, I still haven't had a known bug in production. Games, especially tech art, is riddled with bugs. In contrast, I almost can't open a piece of random tech art code at any company without pretty quickly finding a bug. They're everywhere. I have so many thoughts on TDD, and even gave a long talk with all my epiphanies and discoveries from TDD. Simultaneously, I was also getting into functional programming in Haskell, and still love it. Both it and TDD changed how I code in fundamental ways, and I noticed parallels. They both really focus on separation of concerns, and both push you toward the functional core/imperative shell paradigm (good talk on this from way back: ua-cam.com/video/yTkzNHF6rMs/v-deo.html), which is a very robust way of building code. I left that company where I learned TDD, and found out they were still using all of my tools 5 years later, and still nothing had ever broken. Still no found bugs, even in my half-decade absence.
It's important to make good distinctions about the terms being used otherwise beginners would try to use "TDD" and be frustrated as it doesn't work as expected, it doesn't fit with what it is being told by other devs, or takes too much time. Some limitations of the original TDD (and most of the definitions found online) is that TDD is not fit for non-deterministic systems and for graphical applications (games tend to be both of those).
I said this because the video doesn't disclose which definition of TDD (i.e, from what author) is using. The first TDD definition (the one popularized by Kent Beck) and even the one you find of wikipedia, doesn't make mention of requirements (those are more for BDD and acceptance tests) and this video makes omission of TWO very important aspects of TDD: the refactoring step, and the possibility of going in small steps for developing.
Also, I have to check the test written in this video, it peaks my curiosity since I'm pretty sure there must be a mathematical way to prove that the fix will work with any angle and with a good variety of shapes for the player object instead of just using fixed angles as test cases. Full disclosure, you don't need to implement the "mathematical way" for testing features because one, they tend to be more complex to understand and maintain, and two, they add a barrier for collaboration, so the fixed angles are good enough. If the bug is reported again for cases not covered, then it may be worth exploring the "mathematical way" tho
Tdd is great if you're working on bigger projects, but on smaller projects it may make them take longer for not much gain.
Also note that you may want to run a cycle of random or sweep tests, which may catch some edge cases you didn't know about.
I used TDD in unity in a hobby project. The test-cycle is slow, but it is pretty good. You did a good job explaining it.
This is great! Writing tests is an extremely useful and often overlooked tool that developers have. I think they can be easy to ignore early on in favor of manual testing, but in the long run they are invaluable. imo I'd go as far as saying that if a feature doesn't have a test, it isn't a feature, it's a helpful bug.
Haha, yes. Tests are important even I can be a too lazy to write them right away.
Fun thing is that the corner bug you mentioned in the first half of the video is a well-known glitch in SM64 that allows things like wall clips and other weird behavior. It's cool that even without knowing about the code on Sm64 specifically, you ended up at the same problem that nintendo did, meaning you both discovered the same way of programming movement
Thanks for watching the video and leaving a comment! I didn’t know the jittery sliding at corners was a bug in older games too, I know Portal 2 and source engine have that problem as well leading to fun infinitely velocity glitches.
Bouncing and sliding movement methodology is a well accepted way of having smooth movement over collision surfaces.
These videos are very helpful, thank you
tdd is great for huge collaborative projects where you cannot afford to have a tester test every single commit, for smaller projects the results are diminishing or it can even hamper development
Hi, pretty interesting topic
Thanks! :)
Trouble is now we have satellites & drones, you can just compare photos and track where all the trees are moving to... Don't even need a human to analyse the imagery. And while I haven't heard of anyone doing this, well, I wouldn't hear of it now would I, but I'd be surprised if it's not happening.
0:49 Wait, so you write the test BEFORE writing the feature? 🤔
The problem I've always found with test driven development was actually in the first part of your list - defining the requirements. It is often difficult to know exactly what you SHOULD be testing for before you've actually written the code. The process of coding is largely a process of building your understanding of the problem space. Tests prior to that process often do not reflect what's actually needed.
Not always obviously, and usually you can lay out the basics, but edge cases are certainly not easily predicted and they tend to be where tests become most useful.
As a CS student, TDD is the worst way to develop software (i hated it lmao)
Very relatable, painful but can have good results if applied properly.
As a software developer, TDD is the only way to develop software. I wouldn't write anything that will actually be used without tests. Testing is not optional. All software that's being used will be tested. If you don't automate the tests, your users will test it for you. You know who hates testing your software more than you? Your users. You know who is totally okay with testing your software? The test runner.
It's very satisfying to have a whole application powering half a business run its test-suite containing 1000s of tests in a few seconds. A common complaint I see is that writing tests slows you down: In no way is developing apps with TDD slower. It might be a bit slower at start (especially if you're unexperienced in writing tests), but once you're experienced with writing tests and the application starts to become bigger, these tests will help a lot. Additionally, between all applications I've seen, there's a CLEAR difference between applications that applied TDD and did not: The TDD app will always have a lot less bugs.
If you open our error notifier for all our apps, there will be a huge difference in amount of errors between the tested and untested applications. Additionally, the types of errors differ widely. While the TDD apps only fail in "weird ways" (unexpected scenarios, weird requests, external services with unexpected outputs), the untested applications will overwhelmingly fail in stupid ways like missing methods, NULLs, typos, etc. Only by looking at the incoming errors, you can quickly identify what app was tested and what wasn't.
The problems with not using TDD amplify once you add multiple people to the same codebase. Once there's multiple people involved, you have no longer that mental image of all parts involved, because some parts are not written by you. (Time does the same thing; You will not remember the details of anything you've written some time ago) You'll play an endless game of whack-a-mole of fixing bugs while breaking other parts of the code and you'll end up being afraid of changing anything up to the point of just not wanting to work on the application anymore. You'll be desperate for a rewrite, because the current thing has become a steaming pile of hot garbage. If you're granted permission for a rewrite, you'll just create the same steaming pile of hot garbage.
@@gamebuster800 Just wanted to point out that you NEED to use tests even if youre not doing TDD, maybe youre not familiar with that
@@gamebuster800 To my understanding TDD is specifically coding where you write the tests first prior to solving the problem, right? I don't think it is a rejection of tests entirely. Writing software without testing sounds like hell lol.
@@gamebuster800 appreciate the love but TDD first concern ain't testing