DaedTech

Stories about Software

By

Chess TDD 41: Finishing up White Pawn Movement

This post was the first of another three that I recorded together.  I wanted to tie up some loose ends and move on to implementing pawn movement for black, but I just wound up tying up loose ends.

On a meta note, I’m going on vacation out of the country for a week, so I may or may not be in a position to log in and push posts live this week. It may be a light week for DaedTech posts.

What I accomplish in this clip:

  • Got IsNonCaptureAllowed working properly

Here are some lessons to take away:

  • There’s nuance to when to drive your design/development with acceptance tests versus unit tests.  TDD is generally good when you want to iterate quickly to get a narrow implementation right.
  • There’s no harm in extracting out a method from a test so that you can save yourself typing in the next test you’re writing.  (As long as you’re green while you do it)
  • It’s not relevant to my series, per se, but it’s worth knowing what characterization tests are.
  • Look out for the sunk cost fallacy with your own code.  The fact that you’ve pulled out and spent time creating a method doesn’t mean that the method is actually beneficial or valuable.
  • Beware of iceberg classes.

By

Chess TDD 40: Diagonal Capture for Pawns

This post was the last of a series of 3 I recorded together, so it picks up right on the heels of episode 39 from a flow perspective.  I initially tied up loose ends from the previous episode and then got the pawn’s diagonal capture in place, at least for the white pawns (acceptance tests for black pawns won’t go well right now).  Fits and starts, but real progress nonetheless.

What I accomplish in this clip:

  • Finished the TDD implementation for IsCaptureAllowed
  • Implemented IsNonCaptureAllowed
  • Finally gave pawn diagonal capture ability

Here are some lessons to take away:

  • Always look to refactor test code when it comes to readability and eliminating duplication.  These refactorings are not just for production code!
  • There’s a sizable contingent of people that don’t like seeing the Assert call factored out of unit tests.  Clearly a matter of personal preference, but you may get pushback in a shared code base.
  • In methods, preserve a consistent level of abstraction.  If you have complex two part conditional, don’t factor out one part and leave the other part — make them both conceptually similar.
  • Clean, readable code will look at least vaguely familiar to domain experts, even if they aren’t programmers.  They should see/read concepts that are familiar.
  • Keeping the lines of code low in a class isn’t a first class or all-encompassing goal.  A class can get ugly by having too many methods, even if all of those methods are small.

By

Chess TDD 39: Dipping a Toe into Complex Piece Movement

What I accomplish in this clip:

  • Finished implementing the bishop acceptance tests.
  • Introduced the concept of “capture move” and “non-capture move” to piece movement.
  • Made some good headway on the pawn’s diagonal capture capability.

Here are some lessons to take away:

  • I’ve mentioned this before in the negative a few times, but I’ll phrase it in the positive.  If you’re going to do refactorings, even trivial ones like deleting a dead method, do it with a green test suite.
  • Writing acceptance or integration tests, whether using them to drive design or not, tends to give you a good lesson in patterns of things that can go wrong.  The specific example I’m referring to here is how I noticed that movement for the black pieces from higher numbered rows to lowered number ones tended to be a problem across pieces.
  • Even if you’re not thrilled with a design, you can be productive and get things done with it when your test coverage is good since you won’t be afraid to change it later.  This helps prevent “coders’ block” or “paralysis by analysis.”
  • When you’re reasoning about implementation, allow yourself to stub out helper methods or methods on other objects that will ‘magically’ do what you want.  E.g. if I were writing a “CookDinner” method, I might just declare “TurnOnStove()” and stub it out, to be implemented later.  This practice of defining what before how can help you get toward the single responsibility principle.
  • I won’t belabor the metaphor of tech debt, but having a really high degree of test coverage and a lot of small, modular methods in the code base lets you live with tech debt a little more easily in the short term.  With a lot of crufty code around the problematic code, you’ll never want to touch anything when it comes time to pay it off.  With lots of coverage and good code elsewhere, getting rid of the tech debt at a time that suits you is easier.

By

ChessTDD 38: Bishop Tests and Being Wrong about Being Wrong

For this episode, I did something a bit different.  I actually recorded the coding for this and then two more episodes on its heels.  If you’re following along on github, you’d notice that I’ve checked in code for episode 40, though I still need to do the audio for those next two episodes.  In this particular episode, I get off to a nice start with testing for bishop and then get a bit derailed.  Luckily (spoiler alert), I get it straightened out in next episode.  And, for all 3 of these, I successfully kept to right around 20 minutes.

What I accomplish in these clips:

  • Implement part of the acceptance tests for bishop.

Here are some lessons to take away:

  • I find a lot of benefit in stripping everything but what I need in default templates I’m provided (e.g. the spec flow feature file, an web.config file, etc).  I prefer to be as deliberate as possible about everything that goes into the software work product.
  • No matter what you’re doing, if you do it brainlessly, it won’t go well.  I avoided copy and paste to avoid brainless mistakes, and just wound up brainlessly typing in the wrong thing by hand.
  • TDD lets you poke at and test the code to see if you can get to green (or red) without fully understanding what you’re doing, but if you do this, make absolutely sure you spend time immediately afterward writing tests or reasoning about the code so that you do understand it.
  • You almost certainly won’t stop yourself from making stupid mistakes, but you can develop techniques for discovering them more quickly and reducing their impact scope.

By

ChessTDD 37: Cleaning Up and Implementing Rook

Got back in the saddle with this episode, and had a shorter recording that basically went well.  Someone pointed out in the comments that I had reversed king and queen position for the black pieces, so I started off by fixing that, and then moved on to fixing a bug and finally implementing the Rook acceptance tests.  Wrapped it up in relatively short order, too.

What I accomplish in these clips:

  • Fixed my template for the full chess board.
  • Fixed the vertical version of that reverse bug from last time.
  • Implemented rook acceptance tests.

Here are some lessons to take away:

  • It’s important to understand past shortcomings of your code so that you can form good hypotheses about where you might have other potential weak spots.
  • If you’re going to run an experiment on your code, do it from a test that you’re writing instead of through the GUI or the debugger or something.  You’re running the experiment anyway, so you may as well capture the results in the form of an automated regression test.
  • A lack of test coverage for a line of code isn’t a problem in and of itself.  Coverage is a metric and not a goal.  The problem with having code not covered by tests is that there’s nothing to prove that the code was implemented in a thoughtful, deliberate way.  If you don’t have a test expressing what a path through the code is supposed to do, there’s no way to know if you’ve reasoned about that code.
  • Copying, pasting, and adjusting often winds up taking longer than typing by hand.  You spend more time staring dumbly at the screen trying to figure out what’s wrong than it would have taken you to hand type the code you need.

By

Career Advancement for the Low Price of Your Soul

When I was a kid, I remember my little brother watching Disney films pretty much constantly from the ages of probably 1 to 6 or so. As a result, I have an embarrassingly encyclopedic memory of the plots and songs of the movies from that specific time window. Probably at the epicenter of this Disney knowledge for me was the film, “The Little Mermaid” and I can remember that crazed chef chasing Sebastian the crab around and still giggle to this day. But of all of the songs in that movie, there’s only one that makes me think of the corporate world. I’ll come back to that.

Claw Back, Disney Style

There are a few standard perks in corporate America (and, I’m sure the world, though I’m only familiar with hiring in the USA). Health insurance is pretty much table stakes for serious employment these days, and with a decent employer contribution to boot. Paid time off is certainly up there, along with holidays and general human decency, one would hope.  There’s another tier that includes 401K contributions or some other retirement provision, perhaps a pension of some kind, things like life and disability insurance, and so on.  And, then, you start getting into a land more exotic where employers offer weird, unexpected stuff like “take your dog to work day” or sabbaticals or something.  One that usually shows up in this slightly more exotic realm is some concept of tuition reimbursement for employees that seek degrees or want to acquire skills through classes, certifications, etc.

This perk is a classic win-win situation.  The company invests in the career development of an employee and, in exchange, reaps the benefit of the employee’s learning and added skills.  The employee becomes more valuable to the organization by virtue of new knowledge and skills and, all other things being equal, will wind up earning more money over the course of a career.  What could be better than this arrangement?  Employees donate their spare time to improving themselves for their companies and companies donate money to the cause.  Sounds like a pretty good exchange of consideration.

And the company, really, just wants to help.  Advancing one’s skill set and education isn’t cheap, and there are so, so many poor unfortunates that just can’t afford it.  You know what?  I’ll let Ursula from the aforementioned Little Mermaid explain.

Poor unfortunate souls,
In pain, in need!
This one longing for more skills
That one wants a new degree
And do I help them?
Yes, indeed!

UrsulaContract

Read More

By

ChessTDD 36: Acceptance Tests for Queen Movement

This episode went smoothly until I discovered a bug.  Philosophically, I suppose this is the natural state of software development.  For my purposes here, though, hunting down the bug caused the episode to balloon to 26 minutes, so I’m going to try a new thing so as to keep the videos a reasonable length of time.  I’m splitting it into 2 videos: parts A and B.  Please let me know if this approach is preferable to sometimes having long videos or not; if you leave feedback, I’ll more likely do it the way you prefer, since I’m just trying to go with what people like.

What I accomplish in these clips:

  • Created a couple of code snippets in CodeRush to get rid of the hand typing in the specflow scenarios.
  • Wrote acceptance tests for the queen’s movement.
  • Squashed a subtle bug (or at least half of one).

Here are some lessons to take away:

  • Projects go better when there are more eyeballs on them.  Run things you’re doing by other people and see if they have suggestions that might help.  They may think of things that never would have occurred to you and might later seem obvious.
  • Whenever you make mistakes copying and pasting, it’s a crapshoot whether fixing them takes more time than you would have spent hand-typing or not.  In my experience, most of the time you don’t come out on the winning end, and wholesale copy-paste obscures your understanding.  This is why I try to avoid the practice.
  • What I find is that unit tests should be very directed and specific about system behaviors.  But acceptance tests let you put on your exploratory testing hat, dreaming up scenarios in which users might use this thing that could potentially break it.  For you unit testing newbies, fight the urge to write unit tests with lots of assertions that cover a lot of ground.  You can express that in your acceptance tests.
  • Once again, don’t do low-hanging fruit refactorings (e.g. deleting dead code) when you have red tests.  It might seem like it’s not a problem, but it will come back to haunt you at some point.
  • Another example in this episode of finding a bug with a failing acceptance test, and drilling in to get closer by writing failing unit tests.  This is an excellent and helpful practice.
  • TDD facilitates Eureka moments where you try something you think might work and you see all of your tests go green.  However, just like trying something in your code and seeing the application magically behave correctly next time you run it, it’s important to cement your understanding of why it worked.  Don’t program by coincidence, even if you have a green test suite backing you.  Keep writing tests and/or reasoning about the code until you’re sure you understand what’s happening.  (Writing tests provides an excellent way to prove your understanding to yourself).

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.

By

ChessTDD 34: Specflow for Pawn Movement

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.

By

ChessTDD 33: Scenario Housekeeping

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.

Acknowledgements | Contact | About | Social Media