Chess TDD 5: Bounded Collections of Moves
Really no housekeeping or frivolous notes for this entry. It appears as though I’ve kind of settled into a groove with the production, IDE settings, etc. So from here on in, it’s just a matter of me coding in 15-20 minute clips and explaining myself, notwithstanding any additional feedback, suggestions or questions.
Here’s what I accomplish in this clip:
- Change all piece GetMovesFrom methods to use BoardCoordinate type.
- Got rid of stupid Rook implementation of GetMovesFrom()
- Made a design decision to have GetMovesFrom take a “board size parameter.”
- Rook.GetMovesFrom() is now correct for arbitrary board sizes.
- Updated Rook.GetMovesFrom() to use 1 indexing instead of 0 indexing to accommodate the problem space.
- Removed redundant intsantiation logic in RookTest
- Got rid of redundant looping logic in Rook.GetMovesFrom()
Here are some lessons to take away:
- Sometimes you create a failing test and getting it to pass leads you to changing production code which, in turn, leads you back into test code. That’s okay.
- Sometimes you’re going to make design decisions that aren’t perfect, but that you feel constitute improvements in order to keep going. Embrace that. Your tests will ensure that it’s easy to change your design later, when you understand the problem better. Just focus on constant improvements and don’t worry about perfection.
- “Simplest to get tests passing” is a subjective heuristic to keep you moving. If you feel comfortable writing a loop instead of a single line or something because that seems simplest to you, you have license to do that…
- But, as happened to me, getting too clever all in one shot can lead to extended debug times that cause flow interruptions.
- Duplication in tests is bad, even just a little.
- It can sometimes be helpful to create constants or readonly properties for common test inputs and descriptive names. This eliminates duplication while promoting readability of tests.
it would be very nice if you could increase the font size of spread-sheet when you record next episode
.
Good idea. Definitely will do (though not until part 7 since the screen capture is already recorded for part 6).
I’m not sure if you’ll get to this in a later episode, but I’d be interested in a bit more background about why you dislike duplication in tests. Afaik this isn’t common sense (in the sense that everyone believes it), and my experience differs. By extracting a lot of logic to befores, tests get slower because it’s unclear which part of the before belongs to which test, so unnecesary code gets executed. Another problem with extracting common logic is that it makes it harder to read the tests imho. If you extract nothing, the test reads exactly like what happens,… Read more »
[…] post started out as a response to a comment on this post, but it started to get rather long for that venue, so I’m making it its own post. The comment […]