DaedTech

Stories about Software

By

ChessTDD 35: Acceptance Tests for Knight Movement

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.

4 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Илья Марголин
Илья Марголин
8 years ago

Did you consider to use capital letters for white? like white pawn is P and black pawn is p? Variable chess board size looks very weird! It’s like allowing additional pieces through the polymorphism! “The piece at (2,2) should have exactly…” in acceptance tests does actually not read very easy. If you target chess players, you should go “e2-e4”, if you target programmers you should probably just make another board and show position where the piece was before the move by say ‘!’ symbol, and the positions where piece could go be the symbol of that piece (that would later… Read more »

Erik Dietrich
8 years ago

Can you clone my repo and show me the suggestions you’re making? I’m interested, but having trouble picturing all of it. I have a passing understanding of the rules of chess and used to play casually when I was young, so I could stand to learn more about actual notation/visualization.

Guy Boicey
Guy Boicey
8 years ago

I will take a stable at it, this would be a trade off between what SpecFlow can do and what Chess people do. First add a BoardCoordinate.For that takes a string and returns a BoardCoordinate. This is a rude implementation of course, there are no boundary checks on the For method. I cloned the repo and started to make some tests in BoardCoordinateTest. var coordinate = BoardCoordinate.For(“e2”) public static BoardCoordinate For(string coordinate) { int x = Convert.ToInt32(coordinate[0]) – 97; int y = Convert.ToInt32(coordinate[1]) – 49; return new BoardCoordinate(x, y); } Then in SpecFlow feature and code behind logic to parse… Read more »

Erik Dietrich
8 years ago
Reply to  Guy Boicey

I put the suggestion about changing knight from “Kn” to “N” on the Trello board. With the idea of a more comprehensive switch to traditional and domain-oriented way of indicating chess moves, I’m wondering how easy it would be to decouple the notation from the implementation (off the top, I think there’d be a good seam for this, but I haven’t tried). What I’m envisioning, in essence, is a possible way to deposit a second group of SpecFlow tests that are more “chess-flavored” and have it just work out of the box. If we could pull that off, it’d be… Read more »