Unit tests and Test-Driven Development

[RantingRodent]

Has anyone here employed these techniques in Roguelike development, and have they paid off as much as I suspect they would?

[purestrain]

I did (started-, but its not worth the effort since its only a game. Maybe for minor things like dice throws, area checks and so on. Since games are always based around some random number generator it's even not well suited (of course you could inject a RNG which generates a sequence you defined before).

It's maybe usefull to discover how hell your dungeon generator works, since i'm generating hundreds of dungeons within one unittest run and check if its connected and solvable; otherwise i throw a exception with the seed.

[Krice]

I don't know what unit test is, so I haven't used that.

[Etinarg]

http://en.wikipedia.org/wiki/Unit_testing

If you use Java, just google "junit"

Otherwise, a unit test is just a piece of code that calls a module (unit) API with predefined values and checks the results for correctness. This helps to quickly retest your code after changing something (regression tests). Also, it minimizes the amount of manual tests needed and therefore speeds up your testing process. Furthermore you can include these into automated scripts, which e.g. run all tests on a nightly build, so each day developers see how well or how badly yesterdays version performed - less useful for a single person project, but still.

Edit:

In case of single person average RL projects I'd assume one only wants to do unit tests for a few subsystems, like combat, magical effects, pathfinding and such - just to be sure that after a change these still work as desired. Also easily testable are things like picking up an item, walking one step etc ... more difficult to test are shop actions - unit tests are generally not very well suited to test UIs, there are other test methods that fit better.

[Krice]

In roguelike scene players are good testing units.

[RantingRodent]

Thanks for the input. In this case, I'm not aiming for an average RL project, but rather a long-haul type of project (see: Dwarf Fortress). So I expect to need to refactor most of the game systems over time. Unit tests make that a lot less of a scary prospect.

I'm actually planning to take the unit tests to the most serious extent; Test-Driven Development stipulates that you write a unit test first, watch it fail, and then only add enough code to satisfy the test. Lather, rinse, repeat. Some people I really trust swear by it, so I thought I'd give it a shot.

I'm almost to the point of actually rendering a room and an actor to the screen and so far it's pretty comfortable. I'll be using my blog to share the latest version of the game every week. I'll post a link here when I post the first update.

[Krice]

Thanks for the input. In this case, I'm not aiming for an average RL project, but rather a long-haul type of project (see: Dwarf Fortress).

What you need is a modular data-driven engine. It's the best way to control the variables of a complex roguelike. I think unit testing is a backwards way to do things, because using a test you already assume that your piece of source code can fail.

[Etinarg]

... you already assume that your piece of source code can fail.

This is a reasonable assumption, I think. Only very rarely code does not fail in one way or the other.

[RantingRodent]

The code that doesn't fail today will fail tomorrow.

[RantingRodent]

I've started to work on my game. I'm keeping a development blog here: http://blog.andrewtraviss.com/?cat=30

So far I am enjoying the TDD process. It has roughly doubled the time required to implement little things, but I think I made back most of that time working on the physics.

Should I keep the discussion in this part of the forum until it's  more of a game, or should I move it over to Early Development Feedback now? I actually could use some feedback already about how I've implemented running.