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.