A few weeks ago I was invited by the folks over at Elegant Code to do an interview about myself, agile and the stuff I’m working on in VSTS. The podcast for that went live today:

http://elegantcode.com/2009/01/26/code-cast-19-peter-provost-on-agile-visual-studio-2010-and-architecture-tools/

Enjoy!

For a long time I’ve made the analogy that the best software development teams are like basketball or hockey teams, and lately I’ve been thinking more about how you can recognize what kind of a team you have by continuing this analogy and looking for similarities and differences.

In sports there are a few different kinds of teams. There are teams like gymnastics or bowling where the final result of a match is a result of the combined individual efforts of the team members, but the efforts of the team members aren’t combinatorial. In other words, on an Olympic gymnastics team, the team medal is awarded to the team who’s combined individual scores are the highest. On a bowling team, each player’s score is added together and the team with the highest total wins.

Another kind of sports team is the kind you see in American Pro Football. Here we have one team that is subdivided into two or three parts. The offense is a sub-team that works together to score points. The defense is another sub-team that works together to prevent the opposition from scoring points. There are other sub-teams for special activities like punt returns, field goals, etc.

Basketball, hockey, soccer and rugby are examples of yet another kind of team. On these teams the whole team is working together for the entire game to accomplish their task. There may be specialists on the team like goalies, defenders and wings who have focus areas, but if the time came for an offensive player to block a goal or even a goalie to shoot and score, they would do it.

The best functioning agile teams that I’ve worked with have been like that last kind of team. We have specialists who are good at certain things, but when the time comes to do some work, anyone and everyone does what needs to be done. We can talk all day about elimination of roles on agile teams, but we know from experience that the best testers are people with a natural bent for it. There are also people who are instinctive toolsmiths and will take small taxes that affect the team and mitigate them by adding script or a tool that benefits the whole team. But when it is time to signup for a task, or pair with someone, or fix the build server, or write a new test harness, everyone on the team is prepared and empowered to do that work.

I have also seen agile teams that are more like American Football teams. The most prominent indicator of this is a separation of developers (offense) from testers (defense). This can work, and a large number of teams work this way, but as with football, sometimes the defense finds itself with the ball and if they may not really know what to do with it. Or even worse, they may not feel empowered to do something with it.

You will also find that there are development teams that are more like gymnastic teams. Indicators of this are things like “class ownership” or "module ownership”. When you find architects who must design all the details before a developer can “code it up” you are likely seeing a gymnastics team. Almost any time you find architectural, design or process siloing, you are probably seeing one of these teams. As with gymnastics, these teams can be successful, but it creates a different culture than the one I’m a fan of.

One of the key differences between these types of teams is the attitude about work and dependencies between people. On a hockey or basketball team, the team must work together to win. You can put an amazing group of individuals together, but if they don’t play well together, they won’t win. Done well, the work is combinatorial, where the effort of one person improves the people around them and thereby improves the team. If someone falls down on the front line in a hockey game, you will be unsurprised when the defenseman continues forward and attacks the goal.

Each subteam on a football team behaves this way, but they can’t cross the boundaries very well. The people on the field are interdependent, but they are still siloed into certain responsibilities and expectations. Some might say that this is a result of the way the game is played, with each side taking turns, but in some college and most high-school football teams, the players play “both ways”, meaning that the same people play on both offense and defense. On those teams, when the ball is intercepted, you are much more likely to see the person with the ball being someone who knows how to run and/or throw.

On teams like gymnastics teams, though, you see something different. The person doing floor exercise goes and puts up a score, then the person doing parallel bars goes next, etc. One person can’t really help the next person other than by making a strong enough score to boost the overall team.

The next time you’re thinking about your team, about roles, about siloing and ownership, take a look around and think about what kind of team it is. Think about what kind of team you want. And think about what the forces are that are driving your team to be one way or another. You might be surprised what kind of team you’re on.

(Photo by jimmybop)

After a spirited discussion this week on one of our internal agile aliases, Eric Gunnerson wrote a post on his blog that wraps up his thinking (and mine) about how to deal with taking dependencies on a non-agile team when your team is running in an agile manner:

Eric Gunnerson's C# Compendium : Taking on dependencies

Recently, I’ve been dabbling with doing TDD in PowerShell. I think there may be a TDD Framework brewing in my head, but at this point I haven't done enough to figure out what such a framework would look like. Often I find that the functions I’m writing depend heavily on built-in cmdlets and BCL types and there can be issues mocking them out when the underlying .NET type isn’t easy to mock out. This isn’t so much an issue with PS as it is an issue with .NET, but since PS is very close to the edge of the world (where the code touches the user), it can be hard to mock.

That said, as with most dynamic scripting evnironments, you can mock out a lot of things. Suppose you want to test a function that depends on get-childitem. Because functions evaluate before cmdlets, you can actually replace it by defining a function with that name:

function get-childitem() 
{ 
return @()
} 

Now you have a naked stub get-childitem that returns an empty array. All is good so far. Next you need a gci that returns a single FileInfoObject and for your test you want to have the “archive” bit set on this file. You try to create a new replacement function for get-childitem:

function get-childitem() 
{ 
$fi = new-object System.IO.FileInfo(“bogus.txt”) 
$fi.Attributes = [System.IO.FileAttributes]::Archive 
} 

But at this point you discover that you can’t set the Archive bit, because the file doesn’t exist.

This is actually a common problem we run into when we TDD up against another API that isn’t mock friendly. In an OO language like C#, I will typically wrap it up in another class & interface that I own and then mock out the interface for my code. This is do-able in PS, but a little more complicated because you may have to implement a fair amount of extra code to create and return a PSObject that has the interface you expect to find in your calling code. (This code can be a lot smaller, but less clear if you want… I opted for clarity):

function get-childitem() 
{ 
$fi = new-object PSObject 
$getter = { return [System.IO.FileAttributes]::Archive } 
Add-member –inputObject $fi –memberType ScriptProperty –name Attributes –value $getter $secondValue $setter 
Return $fi
} 

The challenge with this approach is the amount of code it takes to mock out all of the parts that you need. For example, if you need the Mode script property that comes built in to PowerShell for DirectoryInfo and FileInfo, then you will have to add them to your mock. If you also need to support the setter for the Attributes property, then you will need to add that (and possibly a Note member to hold the data).

As with all mocking exercises, this gets complicated when interacting with real things and since PowerShell is really about interacting with real things, it is hard.

Enjoy!

I've been waiting for them to announce this for a while, but it has finally happened. Jim, Brad and co. have finally released and announced their new unit testing framework for .NET. Here's an excerpt from Jim's post (click thru to read the whole thing):

Announcing xUnit.net

In the 5 years since the release of NUnit 2.0, there have been millions of lines of code written using the various unit testing frameworks for .NET. About a year ago it became clear to myself and Brad Wilson that there were some very clear patterns of success (and failure) with the tools we were using for writing tests. Rather than repeating guidance about "do X" or "don't do Y", it seemed like it was the right time to reconsider the framework itself and see if we could codify some of those rules.

Additionally, the .NET framework itself has evolved a lot since its v1 release in early 2002. Being able to leverage some of the new framework features can help us write clearer tests.

Another aspect of change that we wanted to affect was bringing the testing framework more closely in line with the .NET platform. Many of the decisions we made, which we enumerate below, were driven by this desire. We wanted an architecture which is built specifically for programmer testing (specifically Test-Driven Development), which can also be very easily extended to support other kinds of testing (like automated acceptance tests).

Finally, there have been advances in other unit test library implementations that have not really surfaced in the .NET community.

While any one of these reasons would not necessarily have been sufficient to create a new testing framework, the combination of them all made us want to undertake a new project: xUnit.net.

Jim has been chatting about this for years with Brad Wilson, Scott Densmore, Brian Button, myself and many, many others in hallway chats, at conferences and via email and it has finally happened.

I can't wait to see what people think. Congrats Jim and team!

Wow. After years of work and headaches, my good friend Jamie Casdale has just announced the version 2.0 RTM version of TestDriven.NET.

It has always had a great feature set:

• Right-click and run the tests found in classes, fixtures, projects, solutions, etc.
• Run in the debugger
• Run w/ external runner
• Test failures go to Output window and Task list
• Double click on test failure and go straight to the failing test code
• Configurable key bindings for even easier running of tests

And now adds some very cool new things:

• Code coverage – NCover + Team Coverage
• Reflector support – 'Go To Reflector' functionality available on the Code, Disassembly, Call Stack, Modules, Project References and Solution Explorer windows.
• Repeat Test Run – Redo whatever test-run you did last

But I can't really do it justice, so check out Jamie's post. It has better descriptions, screenshots, and more.

Go get it! Come on... you know you want it.

A few weeks ago I was interviewed by the DDJ/Dr.Dobbs guys to talk about CAB, the Smart Client Software Factory and Agile Software Development.

Now, the first of those interviews is live on ddj.com.

Enjoy!

We all totally forgot to blog about this before it happened, but we can at least point you to the recorded version of the talk. Here’s the abstract:

Join this patterns & practices webcast with the Enterprise Library development team to learn about their experiences doing agile development in a collaborative forum. Experts will share lessons learned, what works best, and what not to do. Hear how patterns & practices distributed teams work with contributors all over the world and the techniques they found most effective for staying together as an agile team.

Brad Wilson, Brian Button, Darrell Snow and I got together and gave an “agile talk on agility” where even though we had a slide deck of candidate topics, we bounced around instead, answering questions from the audience. It was a very fun talk for us to give and hopefully it was valuable to our audience.

You can download the WMV of this talk here.

The patterns & practices Summits are starting again. Up next is the USA West event here in Redmond with keynotes by Alan Cooper, Anders Hejlsberg and GotDotNet CodeSlam with Chris Sell.

This time around I’m involved in two presentations, one with Brad Wilson and one with Brian Button:

Agile Development in the patterns & practices "war room" - Peter Provost & Brad Wilson

Learn how the p&p collaborative "war room" used an agile development process to create CAB and Enterprise Library. Discover how the p&p distributed teams work with contributors all over the world, and the techniques used to stay together as an "agile team". You will hear about the lessons learned, what works best, and what not to do.

Build your own Enterprise Library - Peter Provost & Brian Button

Organizations typically need to create their own enterprise application framework. This session describes how to build this framework using the latest Enterprise Library. You will learn how to how to customize EntLib, how to "factor out" functionality you don't require, how to integrate your own code and existing framework, how to package it to work well together, and how to version manage it going forward.

I’m really looking forward to these talks. I always have fun presenting with both of these guys.

For more information, registration information, presenter bios, schedules, etc. please see the patterns & practices Summit web site.

Hope to see you there!

I was just sent this post by Michael Feathers where he asserts:

A test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can't run at the same time as any of your other unit tests
• You have to do special things to your environment (such as editing config files) to run it.

Tests that do these things aren't bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes.

This is a very interesting set of rules and for the most part I agree with Michael. When I do TDD I try to avoid these things as much as possible. But when I find myself needing to break one of these "rules", I almost always end up doing the same thing.

I create a single minded little class that does that one thing. Then I test it to ensure that it does it. Then I walk away from it.

As an example, consider a business class that needs to pull some information from an XML file on the file system. That is what the customer requirement was. However, I would never even consider putting XML or file system logic in that business component. Instead I'll write a class that talks to the file system and returns some sort of domain model (not XML). I'm now free to test my business component using a mock of this persistence loader, completely in isolation of the file system.

I think Michael does the same thing. He continues:

That might sound a little severe, but it is medicine for a common problem. Generally, unit tests are supposed to be small, they test a method or the interaction of a couple of methods. When you pull the database, sockets, or file system access into your unit tests, they aren’t really about those methods any more; they are about the integration of your code with that other software. If you write code in a way which separates your logic from OS and vendor services, you not only get faster unit tests, you get a ‘binary chop’ that allows you to discover whether the problem is in your logic or in the things are you interfacing with. If all the unit tests pass but the other tests (the ones not using mocks) don’t, you are far closer to isolating the problem.

Frankly, we need both kinds of tests, but these "pure" unit tests are undervalued.

I guess the only part I don't really like is that distinction between other tests and pure unit tests (emphasis mine). I don't think it is safe to ignore these other tests and I don't know what to call them other than unit tests, so I'm hesitant to accept the part of Michael's post where he says, "A test is not a unit test if..."

I would much rather say this: "A unit test should try to avoid..." and then follow it with his five bullets.