Mech Retriever Dev Blog
Continuing work on the BattleScreenDriver. A lot of the basic functionality is there–moving, picking up resources, punching mechs… Though it’s interesting how much time I’m spending writing code to prevent stupid behavior–like making sure you can’t walk off the edge of the world, or deploy off the edge of the world, or punch yourself… It’s funny, when coding the Driver for a given screen, I frequently think “Oh, I’ll just breeze through it since there’s no graphical stuff to worry about.” But I end up realizing just how much logic is in there.
Separating it out is great though–as I mentioned last week, it makes coding and testing easier. It also makes refactoring easier–I factored out a BattleQueue class that really helped clean up the driver.
One thing I find myself embracing more is a BDD mindset. BDD is “Behavior Driven Development,” which refers to TDD (Test Driven Development) except you focus on testing how the end code should behave and not so much how the code is implemented. You can’t always completely get away from testing implementation, especially if you want your tests to be manageable. But I’ve found that as I write test for things in the Driver, I’m naturally factoring out classes like BattleQueue, MapMatrix, etc. I’m also pushing the problem of implementing some of the logic onto such classes, and classes like Player and Mech, even though I’m testing those pieces on the Driver instead of the BattleQueue, MapMatrix, etc. classes.