Home » Posts tagged "tdd" (Page 2)

The Parable of The Road Line Painter

land-0125Way back in the day when lines were first being painted on roads.  The early lines were painted by hand.  In those days, a painter was hired and given a stretch of road to paint.  The first day he got on very well.  In fact, he was one of the best line painters they had ever had.  His lines were perfectly aligned, there were no unpainted areas in the space where there should be paint, and he managed to get 500 yards of road painted.  The average line painter normally did 250 yards in the first day.  The managers who had hired him were quite pleased.

Well, the next day, he came to work and set off on his task of painting the road.  He still had another 500 yards of road to paint.  And yet, for as fast as he was, he was only able to get 350 yards painted that day.  Not quite what his managers expected given his performance on the first day.  But still, better than their average painter, and so they reasoned to themselves, “Maybe he hit an extra hilly patch of road or some other unforeseen obstacle got in his way.”

Finally, the third day, he came in and finished the patch of road he had been given.

Continue reading “The Parable of The Road Line Painter”

Setting up SpecFlow

I’ve been asked to train a group of developers in the use of SpecFlow so that they can use it to write Selenium Tests.  So, in an attempt to “kill two birds with one stone” I thought today’s post would cover how to get the SpecFlow environment setup.  Not only will it help me prepare for the training session I will be leading, but it will help me when I need to set this up the next time because it tends to be a bit confusing when you setup a new project.  You’ll see why in a bit.

Continue reading “Setting up SpecFlow”

TDD Gamification – Turning Test Driven Development into a Game

ge-gam-018When I was in college, there were some guys I hung out with who played this game called “Questions” which they got from some book.  Actually, it was a play.

Anyhow, the basic rules are:

  • You can’t answer a question with a statement
  • You can’t hesitate or make a false start
  • You can’t repeat a question that has already been used
  • You can’t ask a rhetorical question
  • You can’t ask an unrelated question.

There was also this podcast at DotNetRocks where they were talking about a beer app and how they had added game elements to the app by adding badges for various types of beer to get you out of your comfort zone.  Maybe there is one for “My first beer that I liked” because I’ve yet to find something I like.  But give me a good Merlot!

All of this got me to thinking about how we might turn Test Driven Development into something of a game.

Continue reading “TDD Gamification – Turning Test Driven Development into a Game”

Limiting Beliefs of Programmers

screamAt the risk of making half of my audience think I’ve gone off the deep end, I’m going to address a topic that I’ve only recently REALLY begun to understand, in part thanks to Soft Skills.

When I’ve heard the topic of “Limiting Beliefs” come up, it has almost always been in the context of something along the lines of “What the mind can conceive and believe, it can achieve.”  Which is easy to disprove.  At least it is out of context!  I mean really, if I can conceive and believe myself to be a butterfly, it just isn’t going to happen!

However, the opposite is pretty easy to both accept and believe.  And that’s what I want to talk about today.  But even then, it probably isn’t what you are expecting.

Typically, when people talk about Limiting Beliefs, they are talking about patterns and practices you picked up as a kid that are holding you back now.  And while those may be areas that you need to work on, what I want to talk about today is more micro than that, although they may have roots in our past for various reasons, the Limiting Beliefs I want to talk about today are common across nearly every programmer I talk to.

Continue reading “Limiting Beliefs of Programmers”

100% Code Coverage Possible?

100% code coverage

In response to my post “Excuses For Not TestingKris K asked:

There is also another side of Unit Tests. Some companies are so fixated they aspire to have 100% Unit Tests coverage and they make programmers write Unit Tests for legacy code for no reason. Just for the sake of having Unit Tests. … [I] wonder if you had any similar experiences and what you think about this approach. I guess the 100% extreme is better than no tests at all, but it can make the developers very bored and feeling useless.

And my initial reaction to this was, “WOW!  So much to respond to here.  I think this is worth a blog post. Continue reading “100% Code Coverage Possible?”