@cybereality said: 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.

I'm sure that's true, since those things didn't exist when the book was first published. But I think the same knowledge can be obtained from web articles and presentations. I tend to rely on that medium these days, since it costs less, doesn't require bookshelves and stays up-to-date.

Yeah, I was surprised they didn't publish an e-book of such an important text. I don't really like hard-covers and huge print books, I mostly read on a tablet (unless I just get something to collect). That book I read on the computer, because my school is online and they have a library. But it's not available to the public.

@cybereality said: 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.

No, that's designing the function and then the test. If you know the valid input and output, you designed the function first. You had to. You may not have written it down or something, but you designed it already. You may have designed it in pseudo code, but still, you designed it first. And how could the order possibly matter? I took a course in a junior college and we always had to write pseudo code first. The test first? I don't think so. And generally the block size is more important. Once you start doing too many operations in one function, things get messed up and are less re-usable and less readable.

Since you're continuing to discuss TDD, you must want to understand it. Watch the video in my first post starting at 43:48, and you'll see a simple demonstration that shows exactly how it works.

@DaveTheCoder said: Since you're continuing to discuss TDD, you must want to understand it. Watch the video in my first post starting at 43:48, and you'll see a simple demonstration that shows exactly how it works.

You write the test to the code you already know you are going to write. In other words, you designed the function first and have done it so many times that you can already write the test function. And that's as far as I can take with that guy because his speaking style drives me nuts. If you were less familiar, you would have no choice but to write the code first because you wouldn't already know it and the results would be exactly the same.

I think you have a misunderstanding. It's a complex topic, but here is an easy synopsis I found: https://www.agilealliance.org/glossary/tdd/

The basic idea is that you create a specification for your application before you write it. You don't just start coding and add stuff willy-nilly as you think you might need it. You map out exactly what features are in the application (or game) and then break that down into each component or module that is necessary to support that feature. These can be classes, for example, and then break down further into individual functions. You write the specification for the input and output of each function and the expected behavior. Not code or pseudo code, but the purpose of the function. Then you write tests to ensure that the function meets it's purpose before you write the code.

After everything is connected, you can begin implementing the function, but now you know exactly how it is supposed to work and also how it should not work, and exactly what can be passed in and what cannot, and what can be returned and what cannot. And then after your first implementation in code (before you integrate it into the game) you test that the function works to some degree of satisfaction. Nothing is ever 100% bug-free, but if it passed all the tests you can be confident it is at least stable and meets the requirements.

You do this then for each additional module or function, and after all of them pass the tests by themselves, you connect them together, one by one, and make sure they work as a whole. Then finally you give them the real data (e.g. integrate it into the game) and at that point you are basically done because you have verified there are no bugs and everything should work almost perfectly. Though in practice, you cannot test for every possibility, as there are infinite, so there will still be some bugs at the end, but a very low amount or maybe none that would delay the launch.

@cybereality said: I think you have a misunderstanding. It's a complex topic, but here is an easy synopsis I found: https://www.agilealliance.org/glossary/tdd/

The basic idea is that you create a specification for your application before you write it. You don't just start coding and add stuff willy-nilly as you think you might need it. You map out exactly what features are in the application (or game) and then break that down into each component or module that is necessary to support that feature. These can be classes, for example, and then break down further into individual functions. You write the specification for the input and output of each function and the expected behavior. Not code or pseudo code, but the purpose of the function. Then you write tests to ensure that the function meets it's purpose before you write the code.

That makes perfect sense because you didn't write the test first. You designed the program first. Decided what it must do, then broke it down into smaller components and decided what they would do. Finally you decided how you would test them and then wrote the code, which is totally logical. However, when you are at those final stages, does it actually matter if you wrote the code first and then designed the test? No, not really. Someone just arbitrarily decided the test should be done first probably because people were skipping it. Your code would be just as good if you wrote the code at that stage and then then decided the test as long as the same rules for testing were observed. I imagine you would quickly learn the reverse, to write the code so it would pass the test without actually writing the test code. And anyway, I think they are incrementally doing both at the same time more or less. They start with kind of a basic template and then keep filling it in.

It's an interesting topic but I can't see using it for the smallish games I write and I think it takes a familiarity with the code that I don't have since I'm constantly watching tutorials and checking the manual to do what I need.

Well it makes sense and it has been proven effective, but mostly for business software. The point is that the tests clarify the specification. If you write the code first, you might be writing the wrong thing or something that is completely unnecessary. The main point is that the specification is fully completed and detailed before you write anything. Writing the tests first helps in that you are writing to the specification, not designing tests to work with existing code (which may mask the problems). And if you wrote the incorrect code (even if it compiles) your program may not perform correctly. Writing tests first forces the code you wirte to conform to the tests (and thus the specification), so you don't waste time rewriting stuff the way you should have to begin with.

All that said, I've never done this in my career. I learned about it a few months ago in college, and it seemed pretty compelling. But it is more difficult to do in games, because of the artistic aspect, there may not be a "right" or "wrong" way (so example, what is the "right" speed for a character controller?). So I've never done it. But I do want to explore it more because the research is compelling in that it works.

Not to say that you can't mix the two, but this feels like it's becoming a Agile VS Test driven development discussion which is perhaps a bit off topic? Could start a new topic for it so long as such vs debate remains civil.

edit: typo

Right, in general I would say agile is better for games because of the flexibility of iteration. But that might not be exactly the spirit of the thread.

Are they not compatible? I've only read about Agile and have no actual experience with it, but can't you use both Agile and TDD at the same time?

Yes, you can. The style I was talking about is called Extreme Programming, and Agile is different, but they sort of spawned out of the same ideas.

I don't think any of these methodologies are to be followed blindly. It's good to know the gist of each and then apply one or more to a degree that fits the project.

@DaveTheCoder said: Are they not compatible?

Never said they weren't, but Agile doesn't specifically say the testing phase has to include unit tests as far as I'm aware, just that some kind of testing should be involved and would typically follow development.

Okay, I misunderstood your previous post. By "Agile VS Test driven development discussion" you meant "Agile discussion VS Test driven development discussion", not "Agile VS Test driven development".

Agile is based on quick iteration and is broken up into sprints. So a sprint may typically be 1 week (sometimes 2 weeks). You agree at the beginning of the sprint what features will be complete (or partially complete) in 1 week. Then you basically hack it and get it working as soon as possible. At the end of the sprint, then you can test and verify there are no bugs, but the core of the method is rapid development and iteration. At the next sprint, you can decide what worked or what did not, or even change the specification if you find something that works better. So it is a very different methodology.

9 days later

@cybereality said: This book is great. I just started reading for school (about 4 chapters in) but it seems very helpful. Beginning Software Engineering - Rod Stephens https://www.amazon.com/Beginning-Software-Engineering-Rod-Stephens-ebook-dp-B00UANX0E0/dp/B00UANX0E0/

Thanks for the resources! I have been watching and reading a ton about this the past few days and one of my main takeaways is that you build tests to test and ensure that the system behaves as you’d expect- like being able to spawn an enemy and it can take damage as you’d expect and whatnot. You do not, on the other hand, build tests that become tied to specific implementations. .. as far as I could gather.

I think there are some places where TTD could be hugely beneficial for a medium sized game- like being able to immediately test all your classes immediately. Stactory my fruit factory thing is already so complicated that the last thing I added- the reactor/power system, took a week longer than needed.

Another thing about the tests - the way they present the methodology, after the test in in place you’re supposed to get that garbage code in there asap to get the test green THEN refactor right after. Idk something about that really clicks to me

The "refactor right after" part makes sense. The initial code, which was quickly written to pass the test, may be ugly. Cleaning it up right away is easy because you know exactly why it's there and what it's supposed to do. If you wait and come back a month later, you might forget why you wrote it.

That book is great. I'm almost finished reading it, I would recommend checking it out.