Friday, August 31, 2012

the testing of DOOM & unittests

This is in reference to FantasyMathHammer, it's about boring coding stuff and not warhammer specific.

Still here? Cool.

Up until now I've been feverishly adding new units, and any vital special rules those units need (for instance, undead units really do need unstable), but avoiding the less necessary rules like special weapons - like Halbards (I added those last night btw).

I foolishly didn't write unit tests as I was developing and instead tested it by running the app myself and checking the full debug logs I had already added into the app.
Slowly, and surely, checking and debugging anything with this method started to take more and more time. It's also quite error prone, as you can imagine.

Eventually I reached a place where a few things occurred.
  1. Debugging like this was clearly taking more time than if I just wrote a unit test for the same instance. Starting the app, picking the exact units and formations, all took time vs pressing the UP arrow, and enter to run some unittests.
  2. There were vast swathes of code, nay, entire plains worth, which I was afraid to touch in case I broke anything. My testing method meant that I couldn't go back and retest everything, I could only test for a specific case or thing which I had just added. Clearly not a good place to be.
I should have known better, I did really, but was attempting to fool myself. No really, I should have known better. WFB is a massive set of rules, all thrown into the same mix and interacting with each other. What did I think was going to happen? That I would construct a massive & intricate spiders web of interconnected code and it would all be fine? 

Yesterday I decided it was time to pay the unittest piper.

The unit tests I've written in 3 hours have already picked up some juicy bugs:
  • Derpy Mounts: I implemented mount attacks in combat in v0.50. Unittests showed that they were totally broken, the mounts would act as their parent unit and just use their stat line when attacking i.e. Demigryph knight mounts would use their knights statline when attacking. Fixed.
    Demigryph's (and other mounts) are a lot better now. Sorry about that.
  • The Mounts were receiving supporting attacks. Mounts should not get supporting attacks. Fixed.
If you're reading this and aren't a coder of some sort, unittests might sound like some magical easy band aid. They're perfect for my situation. Once they're covering a lot of the app's code it will mean I can add new code, or edit existing code and if I break anything the tests will throw an error in the relevant test case.

The downside is that they're going to be a metric tonne of work and I won't be adding armies or special rules handling while I'm implementing tests. Still, catching bugs like the above ones make it worth while.

MENTAL NOTE:
UNITTEST THE SHIT OUT OF STUFF FROM DAY 1.

Unittests are nice! I like!


2 comments:

  1. Knight Errant9/04/2012 9:11 pm

    Love the app. One thing I noticed is that bretonnian knights do not work according to lance formation rules. Suppose it is a special feature that would have to be implemented, and currently the combat result is still accurate for who wins, but the body count estimate is often drastically lower than reality since the knights have fewer attacks. Keep up the good work though.

    ReplyDelete
  2. Thanks, I appreciate hearing that!

    You're right, the lance formation isn't supported yet.
    I've also been told that Bret's get +2 STR for a lance on the charge, unlike other units which have lances who only get +1 STR on the charge.

    I need feedback like this!
    If you spot *anything* (there's probably a lot!) you think is wrong, please feel free to email me at clockworkcraig[at]gmail.com.
    Thanks again :)

    ReplyDelete

Related Posts Plugin for WordPress, Blogger...