TDD Chess Game Part 6: Starting with More Pieces
I recorded this clip at a home, where I have a pretty old dual core processor that’s really starting to show its age when I have the video capture software running alongside VS2013 with all of my plugins. So, if you see the recording looking a little choppy in places, it’s because I edited out some places where I finished writing a test and was just drumming my fingers waiting for the test to go green or something. No need to show you completely dead time. Note to self — probably time for a new machine here soon.
Here’s what I accomplish in this clip:
- Pretty up Rook.GetMovesFrom() a bit with Linq via refactoring.
- Added Bishop class.
- Implemented Bishop.GetMovesFrom()
Here are some lessons to take away:
- You can write a test that’s green from the get-go if you want another data point prior to a refactoring. Strict TDD says you need a failing test before you modify production code, but you can write green tests to your heart’s content.
- Sometimes inheriting from a base class or implementing an interface is the quickest way to get from non-compiling because of an undefined method to having that method defined.
- Just stubbing out a test method doesn’t constitute a failing test. As long as everything is green, refactoring is fine.
- I personally find that there are occasions when extracting a method or defining a common method is actually the simplest way to get something to pass. So, even though that seems really like a refactoring, it can be your simplest path to get a red test green because it saves re-coding the same thing repetitively.
- It’s perfectly fine to leave a working, but ugly, method and come back the next day/session to refactor. Often times a much more elegant implementation will hit you in the shower or on the drive to your office, and you’ll make short of cleaning up the method when you have this fresh perspective.
And, the video: