DaedTech

Stories about Software

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.

By

ChessTDD 32: Squashing a Subtle Bug

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.

By

ChessTDD 31: Look, We Caught a Bug!

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.

By

Chess TDD 30: Starting To Be Idiomatic With SpecFlow

This episode went so poorly, I thought briefly about scrapping it and starting from scratch… but that would not be true to the premise I established at the outset where I’d do this unedited, flubs and all.  Having finished with the AsciiBoardBuilder, it was time to start putting Darren Cauthon’s ideas into play.  You can read up on that here.  I sized up what he had done and, in spite of knowing very little about SpecFlow, decided that I only needed certain parts of it for my purposes.  This turned out to be a mistake as something that I thought he had just added for illustrative/cosmetic purposes was decidedly non-cosmetic, and it took me a lot of floundering to figure that out.  Now, that’s not uncommon for me, per se — I’m a “figure it out by breaking it” sort of person, but it’s not exactly the stuff of scintillating videos.

Here’s what I accomplish in this clip:

  • Got the first idiomatic SpecFlow test written in the new feature.  Barely.  And ugly.

Here are some lessons to take away:

  • When using someone else’s example as a template for learning something you don’t yet know, don’t jump the gun and start tweaking and changing things before you get the example working.  Do as I say, not as I do.
  • No matter how long you’ve been doing this, you’ll still make off by one errors and get array bounds arithmetic wrong when it’s complicated.  Improve the odds in your favor by using TDD or, by some other mechanism that you come up with, if applicable.
  • When you find yourself writing a good bit of logic in test code (meaning, you’re writing a lot of code that you aren’t test-driving), ask yourself whether you could move the logic to production or find some other way to tease it out with TDD.  You can see by my floundering here that you become decidedly less productive when you’re writing a lot of code and just hoping for the best.
  • Using NCrunch, it’s pretty easy to run quick experiments to help with my debugging.  One such example was to start hard-coding the row/column indices to see for which ones exceptions were actually generated.
  • Similarly, putting a temporary precondition assert at the top of a test method to check your assumptions can also be a big help.  This is what started me down the path of realizing my mistake with the table’s header.  I finally sanity-checked my assumption that the table had 8 rows to find that it really only had 7.

By

ChessTDD 29: Finishing up the ASCII Board Builder

I actually recorded this episode right on the heels of the last one, so that I could keep a good rhythm with the ASCII builder class.  I finished that class up here.

Here’s what I accomplish in this clip:

  • Finished the class, as I mentioned.
  • Moved the class into the production code.

Here are some lessons to take away:

  • Sometimes you’ll write a test that goes red while writing the first line.  According to the strictest discipline, you should make that green and then keep going.  But if it’s a question of writing a few more characters or another line or something to get your fully realized red test into place, I, personally, think that’s okay.
  • If you’re going through your red-green-refactor cycle and, during the course of a refactoring, you introduce lines of code that none of the tests are hitting, be very careful.
  • If you’re in the middle of a refactoring and you start to wonder if maybe you aren’t changing the way the inputs and outputs could work, back out the refactoring work and get to a known, green state.
  • I’ve no doubt covered this before, but TDD is a great way to force yourself to think about how your API behaves with non-happy path inputs.  You’re writing tests that tease out implementation, rather than coding to get something working in a GUI.

By

ChessTDD 28: Preparing for Idiomatic SpecFlow

This week I’m starting the process of engaging more yak-shaving, but I think it’s important yak-shaving. If we’re going to be doing this SpecFlow thing in the series, let’s get it done right. In a post I made last week, Darren Cauthon took the time to put together this gist. I read through it and my eyes bugged out. That kind of visualization is solid gold for this problem space. How powerful is it to be able to show other developers (and hypothetical business stakeholders) these ASCII chess boards and say, “look, this movement works?!” So, I’m asking you to indulge me in the journey to get there.

Here’s what I accomplish in this clip:

  • Created AsciiBoardBuilder class to take strings like “BQ” and “WP” and turn them into pieces added to a Board instance.
  • Got half-ish way through implementing that class.

Here are some lessons to take away:

  • I created something called “AsciiBoardBuilder.”  There was a time when I would have immediately thought to have it implement an IBoardBuilder interface, but I’ve gravitated away from this over the years as it tends to lead to unnecessary abstraction at times.  We can always do this alter if we need some other means of constructing boards aside from just using the Board class itself.
  • In case you’ve forgotten, one trick I use is to create the production class in the same file as the test class at first, when convenient.  NCrunch runs a little quicker this way and you don’t have to flip back and forth between two files.  I leave it in here until it no longer makes sense to, usually (e.g. when some other production class needs to use my new class).
  • I did something that’s a little more complex than your average TDD scenario, wherein I was modifying two different production classes as I went.  This isn’t particularly common and you might not want to do it if you’re new to this or you run into trouble trying it.  But if it works for you, there’s no reason not to do this.
  • If you go look up a solution, such as how to implement a bit of Linq-fu, it’s probably worth writing an extra test or two that you expect to go green just to confirm that you really understand the behavior of the solution that you found.
  • What I did with factoring out GeneratedBoard may not be to your liking.  This has the upside of eliminating duplication but the downside of introducing a bit of indirection.  For me, the improvement in how succinct the test cases are is worth it, but you may not agree.  This isn’t always an exact science — taste does factor in.
  • I’m pretty rigid about strongly favoring one assert per test method.  Not everyone feels this way, but I felt it worth refactoring to assert only one thing: that the piece is a white bishop.  (As opposed to asserting that it’s white and then that it’s a bishop).  I suggest that unless there’s really no option but to have multiple asserts, you factor toward one.

By

ChessTDD 27: Parameterized Acceptance Tests and Scenarios

At this point, I’m not going to bother with excuses any longer and I’ll just apologize for the gaps in between these posts.  But, I will continue to stick with it, even if it takes a year; I rarely get to program in C# anymore, so it’s fun when I do.  In this episode, I got a bit more sophisticated in the use of SpecFlow and actually got the acceptance tests into what appears to be reasonable shape moving forward.  I’m drawing my knowledge of Specflow from this Pluralsight course.  It’s a big help.

Here’s what I accomplish in this clip:

  • Implemented a new SpecFlow feature.
  • Discovered that the different SpecFlow features can refer to the same C# class.
  • Implemented parameterized spec flow components and then scenarios.
  • Got rid of the “hello world-ish” feature that I had created to get up to speed in favor of one that’s a lot more useful.

Here are some lessons to take away:

  • When using new tools, you’re going to flounder a bit before the aha! moments.  That’s okay and it happens to everyone.
  • As your understanding of tooling and your environment evolves, be sure to evolve with it.  Don’t remain rigid.
  • Fight the urge to copy and paste.  It’s always a fight myself, but on the occasion that I don’t have a better solution right in the moment, getting a test green, than duplicating code, I force myself to feel the pain and re-type it.  This helps me remember I’m failing and that I need to make corrections.
  • When I got my bearings in SpecFlow and realized that I had things from the example that I didn’t actually need, I deleted them forthwith.  You can always add stuff back later, but don’t leave things you don’t need laying around.
  • Notice how much emphasis I placed throughout the clip on getting back to green as frequently as possible.  I could have parameterized everything wholesale in a broad refactoring, but I broke it up, checking for green as frequently as possible.
  • Sometimes sanity checks are necessary, especially when you don’t really know what you’re doing.  I was not clear on why 8 was succeeding, since I was querying for a piece off the board.  Just to make sure that I wasn’t messing up the setup and it was never even checking for 8, I added that exception in temporarily.  Use those types of checks to make sure you’re not tilting at windmills.  As I’ve said, getting red when you expect red is important.
  • No matter what you’re doing, always look to be refactoring and consolidating to keep your code tight.

Acknowledgements | Contact | About | Social Media