DaedTech

Stories about Software

Jun
26

By

TDD Chess Game Part 8: Hail to the King

Category: You Asked For It Tags: , , , | 8 Comments

Today’s episode is one with a pretty directed focus. I’m actually typing this prior to doing the screen capture, but I know what I want to do ahead of time. I want to implement the King piece, and I have a relatively good idea how to do it.

Here’s what I accomplish in this clip:

  • Implement King with GetMovesFrom()

Here are some lessons to take away:

  • Sometimes you’ll go into a coding session with a discrete, obvious goal, and other times you’ll have to break a nebulous goal into discrete, obvious ones.  But you always want discrete, obvious ones if you can.
  • If you can save yourself using the mouse via being proficient with keyboard shortcuts, I’d definitely go this route.  The time savings amortize over lots of coding.
  • For “simplest thing” in TDD, it doesn’t always mean that you have to bang out a line of code.  Maybe you can pull an existing method to a common ancestor and use it, or instantiate and use some other object.
  • “Simplest thing” is kind of an art form geared toward your best productivity.  If you’re new to the process of TDD, you probably want to keep it really simple before you’re experienced enough to be discerning.  Once you’ve established it and gotten good at the basics, you can adjust to situational taste.  Perhaps sometimes you’re stuck and need to get really simple while, in other cases, you have a good grasp on what comes next and being obtuse would just be busy-word.  Practice and use your judgment.
  • If you’re using a continuous testing tool (and specifically C#), pay attention to coverage with IEnumerables.  It seems trivial, but it’s really better if you’re executing every line, even if it just means calling ToList() somewhere.

Jun
13

By

TDD Chess Game Part 7: Cleaning up the Bishop

Category: You Asked For It Tags: , , , | 2 Comments

I bet you thought I’d forgotten this series and the video-cast leg of my burgeoning multimedia empire, but fear not, because I’m back following a long vacation, bookended by content publication announcements. I took previous feedback to heart and increased the font size of the spreadsheet as I worked, and decided to make this video a little shorter. Trending closer to the 10 minute mark than 20 is partly selfish because the 20 minute videos take an absolutely staggering amount of time to produce in my video editing software, but I also think it might be more consumable this way. So, here’s what I accomplish:

  • Extended test coverage on Bishop.GetMovesFrom() a bit.
  • Cleaned up Bishop.GetMovesFrom().
  • Moved Bishop to its own file.

And here are lessons to take away:

  • It’s fun to be cute with your todo list, but the effect wears off after a break — better perhaps to keep it simple and descriptive.
  • When you see duplication or repetition of patterns, ask yourself what’s the variable or variables in the repetition and see if you can parameterize it for an extracted method.
  • Use the refactor phase to ask yourself, “how would this method read to someone who’d never seen this code before,” and to focus on how to make it clearer.
  • This is pretty heavy on personal opinion, but I think favoring declarative (functional, Linq-y stuff) over imperative (loops and control flow) semantics promotes readability.

May
16

By

TDD Chess Game Part 6: Starting with More Pieces

Category: You Asked For It Tags: , , , , | 7 Comments

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:

May
7

By

Chess TDD 5: Bounded Collections of Moves

Category: You Asked For It Tags: , , , | 4 Comments

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.

Apr
30

By

TDD Chess Game Part 4: Getting Organized

Category: You Asked For It Tags: , , , , | 3 Comments

Alright, welcome back to this series.

A couple of housekeeping things:

  1. I have bitten the bullet and used the Visual Studio White theme along with 14 point font to record, so hopefully the videos going forward should be easier to watch. It’s a little surreal to work with, but c’est la vie.
  2. The source code is now available on github for you to follow along. The coding is usually running ahead of my publication, so if you want to see the code from a given video, you may have to grab a slightly earlier version.

Here’s what I accomplish in this clip:

  • Started using a little todo list to keep track of what I’ve done and what I need to do.
  • Cleaned up code as reported by static analysis tools.
  • Pulled some production classes into their own namespaces and out of the test classes.
  • Defined an abstract Piece class.
  • Defined a second inheritor, “Rook,” for Piece.
  • Defined a bit of dumb functionality for Rook’s “GetMovesFrom” to get it started.
  • Implemented ability for a pawn to move two spaces on its first move.
  • Defined a piece concept of “HasMoved.” (albeit just for Pawn)

And here are the lessons to take away:

  • Keeping a list of smallish things you want to change can help you keep track of what needs to be done without distracting you too much (I picked this technique up from Kent Beck’s “Test Driven Development By Example.”)
  • If you’re using NCrunch, use the green dots being dark or bright as a quick way to tell if the code is compiling.
  • Gamify cosmetic issues. If “Optimize Namespaces” and things like that are important, make violations ugly and distracting in the IDE and you’ll get annoyed and fix them whereas you probably wouldn’t bother, otherwise.
  • It’s okay to write stupid tests if you do so knowing that you’ll fix them. Finding ways to always write a test to change production code is good for practicing the TDD discipline until it starts to become second nature.
  • It’s okay to write a test that causes a non-compile failure and then needing to do a good bit of work to get everything back to compiling/passing.
  • I’ve mentioned this previously, but it bears repeating: it’s okay to reuse a test (especially a stupid one) to get a failing test.
  • If you weren’t aware of C# yield keyword and deferred execution, it’d be a good thing to familiarize yourself with.
  • Force yourself not to copy and paste as much as possible, even when it seems dumb. Feeling the pain of re-typing things will make it painfully obvious when you’re duplicating code and could do something better.

And, here’s the clip:

« Older Posts
Newer Posts »