TDD: Test design in C# .NET

Posted on June 11, 2010 by adam.miller

I have been practicing TDD for a while now and, to be honest, I have always been so close to our code base and unit tests that I never really noticed that our unit tests were pretty terrible. Recently, a new guy, Jeff, started working on our team and he really helped me realize just how terrible our unit tests were. Granted Jeff had never practiced TDD before and was also new to eXtreme Programming.

Anyway, one day, after Jeff had been on the team for a few weeks, I asked him how he was doing taking everything in.  He seemed a little relieved that I had asked and replied, “Well, the code doesn’t have a lot of comments so I am having a hard time figuring out what is going on.”

So I followed up with, “Well, we do TDD and strive for self documenting code, have you tried to read the tests instead of reading the code itself?”

Jeff’s reply, “Well, yes, but I’m still having a hard time ….”

How could this be? So, I took a step back and tried to see things from his perspective, I looked over some of our tests and immediately thought, “Wow, no wonder he’s having a hard time.”

The problem is that we had written a lot of unit tests similar to this:

This may not seem terrible, especially if you have experience in TDD and Rhino Mocks. Keep in mind though, this is just a quick fictitious example I threw together. In the above format our tests could be very long, with a lot of setup etc. Also, we were naming our test fixtures based on the Class Under Test for easy code navigation in Resharper. We might know we were looking for the ProductCatalogPresenter and it was nice to hit Ctrl-N PCPT and go right to the ProductCatalogPresenterTests.

So, I started thinking on some of the other objectives of using TDD, and what self documenting code means. My objective was to come up with a way that would provide us (current developers of the code base) ways to be able to write tests with the same code navigation potential that we had in our current ways, but also really raise the bar of our test clarity.

I started by looking at just the code of our test methods. I thought to myself, we would never write real methods like this, why are we writing test methods like this. Then I took a look at our test structure and realized that most times we would have 1 test fixture per class under test. What this ended up doing was that if a presenter had 5 methods it would have 1 test fixture, with possibly 10 – 15 test methods, or even more.

I instantly decided that I was going to just change some structure of an existing test, and then try and change the behavior of the developers writing them.

Step 1. Create a test fixture for each behavior. A presenter with 5 methods would now have 5 test fixtures named according to their behavior. Name the code files accordingly and put them in a folder named ProductCatalogPresenterTests. (this is just for good organization)

and

Problem: If I want to go to the tests for the ProductCatalogPresenter Resharpers CTRL-N PCPT would not work anymore.
Solution: Create a partial class to wrap all of my test fixtures. (we normally put each test fixture in a separate file).

WhenInitializing.cs

WhenSavingANewProduct.cs

Now when you use Resharper CTRL-N and PCPT you will see ProductCatalogPresenterTests like usual, selecting it will bring up multiple choices, “WhenInitializing” and “WhenSavingANewProduct” taking you right to the tests you care about.

Step 2. Name Test Methods according to the exact conditions they are testing.

WhenInitializing.cs

WhenSavingANewProduct.cs

Step 3. Drive the test method differently. Before writing anything, write the behavior out in english-like method calls, I call these behavior statements.

Step 4. Fill in the blanks.

The full test is now easy to navigate to with Resharper shortcuts (instead of having to do right click->Find usages), and each test method reads fairly easily. When I presented this to some colleagues one of them brought up a few good points.

1. You are essentially doing the same thing as comments, and now you have to maintain them.
a. Yes, but these new comments are easy to maintain. If this class changes behavior I can use Resharper to update the “comment” for me. When the class changes behavior I will go to my test method and put my cursor on the method declaring the behavior i.e. CreatesProductFromFactory(); hit F2 and Re-define the behavior LoadsExistingProductFromRepository(); and maybe I add more behavioral statements after PromptsForConfirmation(); or whatever, then I just go to the behavioral statement and change it, right click->run tests->red->green->refactor.

2. The code is simple enough, why don’t we just inline it?
a. Yes, its true, each of those behavioral statements are simple enough to be inlined, however, the objective is to keep the test methods as readable as possible so that they can be easily understood in a single sentence. When I read the test method I can easily see “This presenter does x, y, and z, when saving” then when I need to know or care about how it does x I can read and interpret the mock statements, or whatever, at that time.

3. What about code smells?  Couldn’t this hide potential code smells?
a.  Maybe.  What I would suggest is that if the code in a behavior statement is rather lengthy, or their are a lot  of behavior statements in a test method, or a behavior statement becomes ridiculous to express than you might have a code smell.  Remember though, red, green then refactor.  When you write your tests get the behavior you need stated in the test, then when you realize one of the above, refactor them to make them less.

Posted in .NET, TDD | Leave a comment

Iteration planning is more than deciding what stories to play

Posted on May 19, 2010 by adam.miller

A while back during a retrospective I was reflecting on how unsuccessful our iterations were.  We were almost never completing the set of stories we were trying to deliver, had nearly no consistent velocity, and several team members were complaining about feeling like they were never doing story work.  So, I started to re-think the definition of our iteration.  Previously during our IPM we had always just said “lets play these stories because we played this many points last time and it did (or didn’t) work out.”  This time I proposed a new definition to our iteration, “An iteration is setting forth to accomplish a set of goals during a given time period (iteration length).”

Well, what does that really mean?  Obviously the goals are developing, testing, and deploying a set of stories to production.  Right?

Wrong.  The new definition means that an iteration does not just consist of delivering stories to production.  An iteration consists everything that happens from the start of the iteration to the end of the iteration, that includes meetings, interruption tasks, technical debt pay-off, etc.  Of all of this stuff, for lack of a better word, the highest priority items which are necessary to accomplish become the set of goals for the iteration.

Now what does that really mean?

Well, lets check out a fictitious example.

Let’s say that last iteration we delivered 4 points to production, had 3 interruption tasks, and luckily 0 meetings.  For this iteration we already have 2 interruptions on the board, we have 3 stories ready for development with point values of 2, 2, and 5.  We also have a huge pile of technical debt, and we know that we have 1 extra department meeting that is during this iteration that was not in our last.

From this we already know something important.  We (most likely) cannot deliver the same amount of points to production this week.

Why not?

Well in our last iteration we only had 1 interruption and 0 meetings, this week we are going to have twice as much interruption work and we are going to lose part of a day to a department meeting.

Well, that isn’t really that much time, we can still deliver the same number of points to production.  Right?

The real answer here is maybe, and maybe is uncertainty.  Remember, we can only plan what we know we can control or predict.  Let’s continue with this example some more and we’ll re-address this uncertainty later.

So, back in the IPM, we take a look at our plate and through the assistance of the business we determine what the priorities are.

  1. Interruption #1
  2. Story #1 – 2 pts
  3. Interruption #2
  4. Story #2 – 5pts
  5. Story #3 – 2pts

Now we are assuming we can only deliver less points than last iteration, and if we start tallying up story points we realize that we can only fit in the 2 interruptions and the first 2 point story.

Hang on, only 2 points?  That isn’t good enough, we played 4 last time, can’t we just try and play Story #2 anyway?

I agree, this is looking grim.  Let’s remember the new definition of our iteration. “An iteration is setting forth to accomplish a set goals during a given time period (iteration length).”  Continuing on…

We decide that the goals of this iteration is going to be the 2 interruptions and the 2 point story.  The remaining stories are going to be “stretch” goals.

OK, now what does that mean?

It means that we are going to do everything in our power to accomplish the goals of the iteration, and once they are accomplished we will then try and accomplish the highest priority stretch goal.  If we don’t get to try and accomplish our stretch goals thats fine, they can rollover to the next iteration.

A quick side note, a stretch goal should only be started IF it can be accomplished before the end of the iteration, if it cannot be finished before the end of the iteration it needs to be re-evaluated by the business.  If the team and the business say that this story will be in the high priority list of the next iteration than that stretch goal can be started even if it won’t be finished.  Otherwise, move on to a different stretch goal, or paying down technical debt, etc.  We want to optimize our throughput not our utilization here so let’s not start work that has no chance of being done.

So, what does all of this buy us as an agile team?

Well, this helps you plan more successful iterations.  You should be able to clearly define and provide expectations to give to the business and hopefully in combination with other agile practices, over time, you should be able to adjust to a more consistent velocity.

Posted in Agile | Leave a comment

Give me that hammer, I need to make a hole for this TV mount

Posted on May 14, 2010 by adam.miller

I recently read a blog post by Udi Dahan regarding the danger of attempting to use CQRS for everything.  Udi talks about how he is afraid that people may start trying to apply CQRS to everything and that it may be on its way to becoming a “best practice” item.

If your not familiar with CQRS fear not, my post has nothing to do with CQRS.

One of the nice things about Udi’s post is that it has a much broader scope than just how he applies it CQRS.  Udi talks about how it is important to evaluate the business context of the application before blindly choosing to use CQRS.  You see, the fear is that CQRS is this architecture that is becoming a “fad” in the software development community.  The problem is that CQRS is not a panacea architecture.  Frankly none exist, and probably never will, and Udi is trying to point out how important it is to understand this.

Now, I know I said that my post had nothing to do with CQRS and all I have done is talk about CQRS so far.  The message that I am trying to convey is that it is always important to remember to use the right tool for the right job.

For example, I recently had a discussion with some colleages regarding the architecture that they wanted to use in their new system.  During the discussion people were almost instantly talking about wanting to only use this architecture if we could standardize it across every future application in the department.

The problem with this conclusion/statement is that architecture can be as unique to a software application as tools are to their intended application.  Just to be clear, I am not saying that software architecture is 1 to 1 with the applications in which they are being applied.  If that were true there wouldn’t be things called patterns.  However, it is possible to find that the specific implementation of an architecture may be as different from one implementation to the next just like my fingerprint is different from yours.

The important thing to remember is that architecture patterns have evolved from solving similarly structured problems.  When confronted with a specific business problem/need you should always consider whether or not your “favorite” architectural pattern applies to solving that problem.  If it doesn’t, consider searching for a different architectural pattern that does apply to solving the problem at hand.  i.e. If you need to make a hole for your new HDTV wall mount and your hammer doesn’t seem like it would be the best tool, try looking for a drill.

Posted in Software Development | Leave a comment

Throughput vs. Utilization

Posted on January 29, 2010 by adam.miller

There are many books, blogs, mailing lists, etc, on adapting lean agile principles.  My team has recently started adapting some lean principles and I wanted to share a few things that I have learned about going lean.

In short, it is pointless to start what you can’t finish.  Remember, one of the goals of being lean is to minimize work in progress (waste) and maximize throughput (completed work).  In order to accomplish this first we need to plan our iteration, achieve those goals, and deliver that value to the business.  Everything done in the iteration outside of that is waste and is merely trying to maximize utilization under the justification of “we are not busy,” or “we have some free time.”  When we have finished development and have moved those stories into testing we should be doing everything to support testing, getting the users involved in the testing process, getting user feedback about those stories, and preparing for the next iteration.  I.E. Spiking out any architectural or technological issues that may be considered hurdles for the stories of the next iteration.

At a quick glance of lean, some people may think that lean means when you finish a story, you should immediately start the next.  I disagree.  The problem is that trying to add more story work that won’t be finished during this iteration only adds work in progress.  Some people would argue that starting something is “getting a head start,” and means that those stories would just get done faster next iteration and provide value to the business sooner.  This is a misconception.  Starting new story work that won’t be finished is as simple as that, starting something.  Anything that is started and not completed is in progress and goes against our objectives of minimizing work in progress.  Some of the problems with starting this new story and not finishing it is that it skews our plans.  It makes it harder for us to plan the remainder of the next iteration when that iteration starts because we have work in progress.  This also makes it harder to predict and tell users when their stories will actually be completed.  A single mistake in our planning will impact the whole timeline and eventually make us lose trust from our business users.

So, why is maximizing utilization bad?  If everyone is busy working on stuff than that means things are getting done right?  The truth is that the answer is in the question.  If everyone is busy working than nothing is done, it means that everything is in progress.  Lean is about getting things done, getting them out to the user and providing value to the user.  If you end up deploying stories to production on a Wednesday than congratulations you have a successful iteration.  Also, the “extra” time on Thursday and Friday can be used for paying back technical debt, working out new technologies or ideas for new stories, self growth, training, etc.  There are plenty of valuable things to your organization that can be accomplished during that time that does not involve putting more work in progress.

One truth that I believe is global is the 7 P’s; Proper Prior Planning Prevents Piss Poor Performance.  Specifically, under planning and over planning can be detrimental to the iteration and to the organization.  Ideally we will plan the number of story points that we can play in an iteration based on the number of story points we successfully completed the last iteration.  However, there are several other things to consider.  For example, are there any known meetings/events that will slow development/testing time in the new iteration that did not exist in the last iteration.

What are under planning and over planning?  Well, under planning, as I call it, is when you develop, test, and deploy to production all of the planned stories for an iteration, such that there is enough time in the iteration remaining to develop, test, and deploy to production another story.  Over planning is when you cannot develop, test, and deploy to production all of the stories planned for an iteration.  I’ll post more about the detrimental effects of under/over planning an iteration later.

If you under plan an iteration and your next story is prioritized, analyzed, ready for development, and can be completed within this iteration then you should play it.  I just want to reiterate, don’t start it if you can’t finish it.  You should also be sure to address this under planning in the retrospective/IPM.  Identify that you under planned your iteration and adjust your planned story points accordingly.

Also, if you over plan an iteration you must absolutely consider this in the planning session for your next iteration.  If you do not consider that you have unfinished work, even if the only thing that remains is deploying an app to production, then you will over plan again.  If you over plan you need to play less story points.  There are at least two reasons why.  One, the time needed to finish the unfinished work must be accounted for in this iteration.  Two, you just failed playing the previous number of story points, you need to play less or you will fail again and again.

Posted in Agile, Lean | Leave a comment

Oh no. I’ve got to keep on movin’.

Posted on January 14, 2010 by adam.miller

Recently I posted “The key to successful communication is … a refrigerator magnet,” detailing an effective communication tool for interpersonal communication.  While this tool is great for one on one communications in meetings and such, I wanted to give an example of how to apply this tool to a broader spectrum.

In my team we were having a hard time remaining focused in our stand-ups.  Instead of a 15-20 minute stand-up we would sometimes take up to an hour or longer.  The stand-up material would be all over the place like debates about implementation details, QA approaches to a problem, or even what movie someone watched the night before.  As a group we knew this was a problem and tried several things to help keep our stand-ups focused.  One of our team members declared that he was going to be an ‘expletive’ by stopping people when they went on tangents and constantly steering our stand-up discussions back on topic.  Another person decided that they were going to bring an egg timer and start cutting  people off when it buzzed (2-3 minutes).

While these were both ‘good’ ideas which the whole team encouraged, no one actually followed them.  When someone tried to cut someone off they themselves would end up getting caught going off on a tangent.  We needed a solution because our stand-ups were getting out of hand.  They stopped serving their purpose and started to become a long boring meeting.  Sometimes I would catch my self starting to daydream because the topics would get so far off course they had no relevance to me.  For those of you who know how stand-ups are supposed to go you may be shocked.

In one of our retrospectives I brought up how this was affecting me, and our team, and that we desperately needed to stop this from happening.  I mentioned using the tool from my previous post, and how effective it is at keeping conversations focused.  So, we decided to try to adapt it slightly for our use in stand-up.

First, a guy on our team brought in a tennis ball to serve as The Floor.  Then we decided the rules:

  1. Only the person holding the floor may speak.  Everyone else must remain quite.
  2. When you receive the floor briefly summarize what you did/learned yesterday and sign up for tasks for today.
  3. Pass The Floor to the next person.
  4. Everyone must receive the floor and speak.

Stand-ups started with 1 person grabbing the ball and passing it around the circle.  This was almost an instant success and since we have implemented this our stand-ups have rarely exceeded 15-20 minutes.

Posted in Agile, Communication | Leave a comment

The key to successful communication is … a refrigerator magnet

Posted on January 12, 2010 by adam.miller

Several years ago I attended an intriguing course on interpersonal communications, since I have found it useful in every aspect of my life I feel like I should share this information.  I know you’re probably asking why I am posting about interpersonal communications and what this has to do with you, and I promise I will answer these questions shortly.

I promise I won’t bore you about the details of the course, but I want to share a specific communication technique that I learned in the course.  This technique may seem kind of silly at first, and to be honest it is, but the silliness has a purpose, it engages you in the act of communication and helps visually express the roles in communication.

First, why am I writing about this and what does this have to do with you.  I decided to write about this because over the last several years I have noticed that communication is one area where we, as IT professionals, tend to be weak.  Now I’m not saying that we can’t communicate, it’s just that sometimes we are not very good at getting our thoughts across to everyone.

Many times over my career I have sat in a meeting with a business user and some member of the IT community and witnessed an hour pass with less than an inch of progress toward solving the problem.  In my experience it has seemed like more often than not both parties are saying the same thing, yet both parties seem to believe that the other is saying the opposite.  Even when this is not the case I believe this communication tool helps bridge the gap in communication.  I would also like to say that this tool is not only good for the IT community, but that this tool can and should be used anytime there is a problem with communicating thoughts or ideas.

So, what is the tool and how does it work.  Well, the tool is really just some simple rules and a physical object.  In the class I attended we were give white and yellow checkered refrigerator magnets that were called “The Floor”, but in reality you can use anything to represent “The Floor”, a tennis ball, a talking stick, whatever.  I’ll go into more detail about the purpose of “The Floor” shortly, but first I want to lay out the rules.

  1. Only the person who is holding the floor may speak.  The other person must remain quiet and listen.
  2. When you receive the floor you must first paraphrase the other person’s last thought.- If you paraphrase incorrectly you must give the floor back to the other person and they must rephrase their statement and return the floor to you and you must paraphrase again.
    - Repeat until paraphrasing is correct.
  3. After you paraphrase you may speak 1 and only 1 thought.  The other person must listen.
  4. After speaking your 1 thought you must pass the floor to the other person.

That is the basic gist of it, and now you see the silly side of it so let me explain some things.

First, the purpose of using “The Floor” is for practice and as you and others get used to this technique you will find that you will no longer need to use the floor to communicate (though it is always useful to go back to using it if you start to have a hard time communicating again).  Also, for most people this way of talking is strange and silly, the floor helps to visually identify what is going on in the conversation and it helps keep you engaged while listening.

Next, the paraphrasing on your turn is really the key of the whole technique.  When it is your turn to talk you first paraphrase the other person which makes sure that both people understand the meaning and intent of the other persons though.  The conversation can not continue until the statement has been rephrased and paraphrased so that both people understand its meaning and intent.  If someone paraphrased incorrectly you must rephrase, it is not acceptable to say the same thing twice.  Also, when paraphrasing you must use your own words, it is not acceptable to just say what the first person said.  After using this tool for even just a few conversations you will quickly see less misunderstandings.  Another nice benefit of paraphrasing is that it really helps prevent heated arguments.

Finally, speaking 1 and only 1 thought helps keep the conversation focused.  Often people have a hundred topics they want to talk about and things can easily get lost and never properly addressed.  By speaking in turn the conversation stays focused and gives everyone equal opportunity to speak on the subject at hand while avoiding tangents.

I understand that this is silly, believe me, but the purpose of using this technique is that people who communicate often will learn more about how the other person communicates.  After a couple of successful meetings using this technique between the same people you can usually start to notice that rephrasing isn’t needed anymore.  After a while you can stop using The Floor (still important to follow the rules though), and eventually you may even notice that you no longer need to paraphrase each other.

Once you are at this point you can apply this technique anytime you communicate with anyone without having to use The Floor.  Just being concieous of what makes communication successful will improve your communication skills greatly.  If at anytime you start to have problems communicating with someone again, just break out The Floor and get back on track.

Posted in Communication | Leave a comment