Does anyone here use Test-driven development (TDD)?
Do you think it would be feasible and worthwhile for a Godot project?
I encountered it for the first time here, and thought it was intriguing: Clean Code - Uncle Bob / Lesson 4
The demo starts at 43:48.
I gave up about 1/3 of the way through. I skipped over a lot of the molecules and things. I notice a lot of people don't do incremental programming which I always do, which is constantly testing the code and make sure it runs in the smallest possible step. So I'm constantly running my code and making sure it does what it is supposed to do. I didn't even understand what his 3 laws were.
If you actually search for it there are a couple of plugins/addons for test driven development for godot.
OK, that helped a lot. I guess the plugin is called GUT for Godot Unit Testing, and there is a tutorial here: However, I don't think my project is large enough for that type of development. I'll just stick with running it often with some print statements.
Yes, I've read a lot about it but never used it. I think it makes sense, particularly for business software that has strict requirements. In games, it is more of an art form, and you might not know what the correct behavior is until you experiment for days on a feature. So it is not as useful.
@fire7side said: I gave up about 1/3 of the way through. I skipped over a lot of the molecules and things. I notice a lot of people don't do incremental programming which I always do, which is constantly testing the code and make sure it runs in the smallest possible step. So I'm constantly running my code and making sure it does what it is supposed to do. I didn't even understand what his 3 laws were.
You have to watch the whole video, especially the example (a simple stack class in Java), to understand TDD and the three laws,
@DaveTheCoder said: You have to watch the whole video to understand TDD and the three laws, especially the example (a simple stack class in Java).
I think I'll just go through life ignorant. That guy is the most beat around the bush speaker I have ever heard in my life.
His presentation style is unusual. I guess like many lecturers, he has to hook the audience with weird stuff, and pad his lecture so it lasts long enough to justify the big fees he probably gets.
But that's the first time I've seen the concept of Test-driven development, which was completely novel to me.
Thanks. That's very helpful. The tutorial "cheats" a bit, though. It doesn't strictly follow the TDD laws. E.g., it adds some code before writing the test that requires the code.
@fire7side said: I gave up about 1/3 of the way through. I skipped over a lot of the molecules and things. I notice a lot of people don't do incremental programming which I always do, which is constantly testing the code and make sure it runs in the smallest possible step. So I'm constantly running my code and making sure it does what it is supposed to do. I didn't even understand what his 3 laws were.
Do people really not do that? When I get a lot of code written and realize I haven't compiled I get super anxious. I also rely a lot on the editor catching my mistakes and using feedback from compile results to help construct the code logic in my head. I can't imagine people just.. writing hundreds of lines of code without testing once or twice.
I once wrote a GPU physics engine in a compute shader for 2 hours without testing and then I compiled it and it worked perfectly the first time. But this almost never happens.
I think a lot of it is they do these tutorials and many of them just plunk down a long stream of code, probably for time and space reasons and the newbies think that's how it should be done. If you are really familiar with what you are doing, you can write larger chunks of code, but even then, you can make a logic error and finding it can take a lot longer to debug. If you wrote a small amount of code, you know right where the problem is located. If you have it print the expected result, that's pretty much a test. I'm sure that TDD is better, but most of us aren't writing anything that quite deserves that to me.
I humbly request that discussion about testing in general be done in another thread. :wink:
Back to the topic:
As I see it, Test-driven development is basically "specification-driven development". The specifications are stated in the form of executable tests.
If you follow the rules, you're guaranteed that:
A big benefit is that regression errors can't happen. If you need to change the code later, you first write a test that requires the code change, then make the code change that successfully passes the test (and all the other tests).
So we had a course on this in my Computer Science program recently. This was the book we had to read, which is like the bible for software testing. I think people misunderstand how it works, it is not just compiling your code and "seeing" if it works. It's a methodical and automated process to ensure a piece of software exactly meets the specifications. If you read this book, you will fully understand (sadly not in print anymore, but you can still buy used versions). The Art of Software Testing 3rd Edition: https://www.amazon.com/Art-Software-Testing-Glenford-Myers/dp/1118031962/
I think I read that book a long time ago, probably the first edition, back when serious programming was only done on mainframe computers.
The new edition has a lot of new stuff like for web and mobile and cloud testing that I'm sure was not in the original. It was very good.
It sounds like someone fooling themselves into thinking they can test something they haven't written yet. Let's say I'm going to code a game. I don't know what the game will be about. I don't know the location. I don't know what will happen. Now, what is the test for it? If you need to know any of those questions, then you are testing a design, which everyone obviously does.
It is for testing individual components (called unit tests) not the whole game. For example, let's say you have a function that converts local coordinates to global coordinates. You can test this in isolation, with carefully constructed test data (which you've manually computed the correct answer), and then verify that the function returns correctly. Or let's say you have an RPG game with an inventory. You can test that you are able to add or remove items (and that it adds or removes the correct item, that the total inventory size is correct after the insertion or deletion, that the game doesn't crash if you try to remove an item from an empty inventory, or add an item to a full inventory, etc.). The game is just a combination of all these little components, which can be tested.
It sounds like someone fooling themselves into thinking they can test something they haven't written yet. Let's say I'm going to code a game. I don't know what the game will be about. I don't know the location. I don't know what will happen. Now, what is the test for it? If you need to know any of those questions, then you are testing a design, which everyone obviously does.
Keeping in mind that I only learned about TDD a day ago, and have no experience with it ...
How are you going to code the game if you don't know what you want the code to do?
The idea with TDD is that you decide what you want the code to do, then write a test that verifies that the code is doing that. The test will initially fail because the code doesn't exist yet. Then you write the code that makes the test pass. Now you have both the code and the test.
TDD is mainly designed for business software, but it is also used in games, particularly unit testing (which I explained above). You are not testing whether the game is fun or if the design is innovative. You are testing that the individual components of code work to the specification. And if you code a function and you don't know what valid input is and valid output is, then you are just winging it and your code will likely have bugs or not work.
