DaedTech

Stories about Software

May
19

By

ChessTDD 35: Acceptance Tests for Knight Movement

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

Things are really starting to flow with the acceptance tests now. In this episode, not only did I mercifully not uncover any important bugs, but I defined knight movement in acceptance tests in a way that I feel pretty good about. I’m learning as I go about using SpecFlow, which is cool, and as the cherry on the sundae, I actually got episode length back under control with a 17 minute episode.

 

What I accomplish in this clip:

  • Fixed the poor naming I left off with last time.
  • Wrote acceptance tests for the knight’s movement.

Here are some lessons to take away:

  • Naming is so, so, so important.  It may seem like a trivial thing, but leaving a method about chess piece movement where “origin” and “destination” were reversed would, sooner or later, cause someone a serious headache.  It would also probably make them hate me when they looked at the history.  Make sure your names are good.
  • You have to do a fair bit of fumbling when you’re figuring out a new tool/tech/framework on the fly.  Stick to your principles and be sensitive to the idea that there’s probably a better way to do a lot of the things that you’re trying to do.  Ask people, and read a lot if you can.
  • There’s a lot of out of the box stuff that comes when I make a SpecFlow feature, but I just get rid of it.  For me, it’s helpful to eliminate everything that I’m not using so as not to be confused about what’s mandatory and what isn’t and also not to be confused later about what functionality I’m even using.
  • An interesting tradeoff emerges in my use of SpecFlow.  Duplication is, by and large, pretty bad in a code base.  But, in the case of visualization, showing the chess board for each individual acceptance test may be helpful in that it makes it crystal clear what’s going on in each test.  There are probably various strategies to try optimizing for minimized duplication and maximized visualization simultaneously, but it’s worth bearing in mind that everything in software development is a matter of tradeoffs and it’s best to be deliberate about whatever choice you make.

May
10

By

ChessTDD 34: Specflow for Pawn Movement

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

This episode featured a return to progress toward shippable features.  I refactored the first feature that I’d started to use the new, idiomatic Specflow approach.  This resulted in it making the most sense to have this be the feature for pawn movement and thus progress toward implementing the pawn’s movement as well as shaking out more bugs.

What I accomplish in this clip:

  • Refactored the old Specflow feature to look like the newer one.
  • Deleted a bunch of now-dead code and made the Specflow backing class a lot more concise.
  • Implemented HasMoved from the board perspective.
  • Fixed a bug in GetMovesFrom

Here are some lessons to take away:

  • I made a mistake in deleting dead code when I had a red test.  Part of the reason I got this wrong was that the IDE crashed and I sort of lost my place, but there’s a lesson here.  It’s easy to get distracted when you see dead/unused code (or something else similar) and go off on a tangent.  That’s fine, but be sure you’re green when you go off on tangents.
  • Thinking ahead about how they code you’re writing will be useful elsewhere is a double edged sword.  It’s good because it can lead to more efficiency and less future rework, but it’s also the first step along the path to gold-plating.  There’s no exact how-to I can offer for walking this line, but just being aware of it will help.
  • When things go wrong with acceptance tests, which are coarser-grained, integration tests, your next stop in figuring out the problem will generally be to move down the test pyramid and look for more details in your unit tests.  Unit tests are going to exercise the code in more granular fashion, so you should get good insights there.
  • I recommend favoring domain-specific, communicative exceptions coming out of your code rather than allowing boilerplate exceptions to be thrown to your callers.  If someone using your code gets an array index out of bounds exception or a null reference exception, they can’t be sure whether you screwed up in your code or whether they screwed up calling your code.  If you, instead, throw “BadBoardCoordinateException”, it’ll be very clear to callers of your method that you’ve anticipated what’s going on right now, and that they’re doing something wrong.
  • Deferred execution with Linq is really powerful and allows you to do some great things, but it also leads to subtle bugs.  I’ve written about this in the past, even.  Be careful and always remember to make sure you’re aware of whether or not you’re enumerating the sequence when you run into stuff like this.

May
1

By

ChessTDD 33: Scenario Housekeeping

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

Having fixed some bugs in the last few episodes, it would have been nice to make some progress with functionality, but there was housekeeping to be done first. I did some refactoring for board setup using the tables, compacting methods, and made the implementation of the moves checker correct. This will put me on much more sustainable ground as I go forward implementing game scenarios.

What I accomplish in this clip:

  • Fixed incorrect/incomplete implementation of checking for moves.
  • Refactored BuildBoardFromTable method.

Here are some lessons to take away:

  • When you make a test go red, don’t then take the opportunity to do a refactoring — even a small or inconsequential one.  Go back to green and then do it.  You want to be taking actions in batches as small as possible.  Doing 2 things at once is a recipe for confusing cause and effect.
  • I’m not sure how others feel about this, but I did something in this video that I do from time to time.  I had a green test covering an implementation that was too permissive — too easy to get right.  So I altered the test temporarily to green in a situation where it should have been red.  I then modified the production code to get the expected red, then reverted the test and verified that it was green.  This is the equivalent of writing another test, framed in the negative, and then taking that test from red to green.  I shortcutted that process because I didn’t want that other test to be left around when I was done.
  • I consider baking the names of types into class, method, and variable names to be a bad practice.  You might change the type they use and forget to update the name accordingly, and you’re also leaking implementation details.
  • A refactoring may well never seem perfect to you.  If you make sure it seems cleaner or better as compared to where it was, that’s progress.  Stick a pin it it and make a note to revisit later.  Not only is this good for avoiding diminishing returns on a given day’s effort, but it also removes you from the problem so that you can better assess readability later.

Apr
26

By

ChessTDD 32: Squashing a Subtle Bug

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

This was kind of a wild episode, inasmuch as recording oneself writing code gets wild.  This was the second bug driven out by the acceptance tests, but this one was subtle and buried fairly deep in the application logic.  This was another half hour episode as I employed a variety of techniques for hunting down and fixing a bug.

What I accomplish in this clip:

  • Fixed the bug discovered last time.
  • Left a few legitimate tests as breadcrumbs along the trail.

Here are some lessons to take away:

  • Use binary search kinds of techniques when solving problems.  For instance, if a two part boolean expression is causing a test to fail by returning the wrong result, comment out/delete one of the branches to see which one it is.  This helps you narrow the search without invoking the debugger or squinting at the code, scratching your head.
  • It’s important, when you have a failing acceptance test, to drill in and recreate the scenario in unit tests with less setup context around it.  This ensures that the problem is, in fact, a problem of the code under test rather than something going on with the acceptance test setup.  Getting this second failing test prevents you from chasing phantom bugs in your production code.
  • I try to use the debugger as little as possible when doing TDD, especially with the continuous testing tool.  But, for the occasion that you’d have to write a lot of assumption checking asserts, the debugger can be a handy way to see a number of different values that you want to check.  This was relevant when I wanted to see 4 different coordinate values.

Apr
21

By

ChessTDD 31: Look, We Caught a Bug!

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

A bit of time went by between when I recorded the code and when I narrated it, so pardon the unusual amount of rust there. But this episode was particularly interesting because an actual bug emerged and I fixed it. Yay for acceptance tests. After that, a second bug emerged, but I ran out of time. So there’s definitely a todo for episode 32.

What I accomplish in this clip

  • Got away from the C&P implementation of “then” for the new style of tests and implemented a usable one.
  • Discovered and fixed a bug in king’s moves.
  • Discovered another bug to fix next time.

Here are some lessons to take away:

  • When you’re stumped by behavior, particularly in integration tests, the continuous testing tool can help you run experiments very quickly.  Add a precondition assert to verify that your assumptions are correct.
  • TDD is not a catch-all against bugs, by any stretch.  I had a dumb bug in the implementation of the King class that I failed to catch, and everyone following along failed to catch (assuming someone would have reported it, anyway).  It wasn’t until I started simulating real production usage that these bugs started to be revealed.  Acceptance tests are critical.
  • The balance between ATDD and TDD is beneficial.  You’ll see going forward that when I find problems, I tend to use increasingly specific tests the way that you might be used to using step-through in the debugger.  Narrowing the scope of the problem with tests rather than the debugger has the advantage of leaving a trail of breadcrumbs that become guards against regressions as you go on.
  • This ATDD/TDD stuff works.  As you can see, I caught 2 bugs that could have escaped into production.
  • Never commit with red tests, obviously, but I also say never take a break with red tests (the way I would have to between clips).  If you have to go, comment or delete that red test, so that you can start fresh with green next time and reintroduce it.

« Older Posts
Newer Posts »