Unit Testing

[Temaran]

I’ve seen some threads on the forum that play around with the idea like this one:

Unit Tests Seem Overly Complex to Add

I think I’ve seen some others as well, but I couldn’t find them with my searches, I’m sure they’re there with the correct search terms though.

There is support for it in the engine though, you have these resources:

Automation System Overview

Automation Technical Guide

Like they suggest, for concrete examples in the engine, TimespanTest.cpp seems to be a good place to start.

Following this point is more of a tangental rant from my part… you have been warned >_>

I like writing tests in my day job, and I occasionally do TDD when it fits the stuff I’m doing at the moment. The problem for me is that I do a lot of experimental programming, and writing games is also very similar to that, which I guess is why most game programmers avoid it. Another problem is of course time constraints, especially within the gaming industry.

That article seems well written, and it basically condenses most of the basic principles in Kent Beck’s excellent book on the subject “Test Driven Developement: By Example”. It’s pretty old, but it’s still probably the best book I’ve read on the subject and they also mention it in the article :), but later on they also touch on the biggest problem that I also mentioned regarding experimental programming (part 3 in the series).

Experimental code. If you’re just experimenting, putting together a prototype, or doing anything that is going to be thrown away, then there’s probably little benefit to using TDD. This is what XP calls “spikes”: short tasks with the intent of experimenting with something to learn more about how to proceed. There’s very little reason to use TDD in this situation.

I don’t think I personally would recommend using it in UE4 or in game dev at all except for the things where it makes sense. Examples of that are the parts of code that are very easily specified, like your math library, your physics engine, your lighting code etc. Fortunately for us, epic has already taken responsibility for almost all of these systems, which leaves us with writing the experimental gameplay code.

So maybe if you were writing a game where you are very certain exactly how you want the game to be, and you have design docs for everything, maybe in those cases TDD would be appropriate, but then again, if you basically remove all creative freedom from the development process by doing that, where is the fun left in making the game?

I think that my preference will always be to really spend a good amount of time in making sure the architecture is simple but robust enough to keep adding features to the game without introducing bugs. And keep the code well structured enough to squash those bugs if they manage to make it through.
Just doing that and having solid, experienced programmers makes TDD close to obsolete in my opinion.

One book I can really recommend for any development really (except for maybe the chapter on TDD when it comes to games then, hehe) is Clean Code by Robert C. Martin. I don’t agree with some of it, like most people with most books, but It’s really quite funny and has a very beautiful vision when it comes to software engineering.
My favorite quote is probably:

Clean code is simple and direct. Clean code
reads like well-written prose. Clean code never
obscures the designer’s intent but rather is full
of crisp abstractions and straightforward lines
of control.

Even though Clean code actually quotes that from another book XD (Grady Booch’s Object Oriented Analysis and Design with Applications).
Still the book is full with nice passages like that one.

I kind of went on some tangents here… sorry about that, but this is a subject we talk quite a lot about at my workplace, and I couldn’t help but gush :3

Best regards,