Software Development is a Team Sport! : Test

Unit Testing Goes Pro!

aridle — Thu, 29 Mar 2007 04:45:00 GMT

According to Naysawn Naderi, VSTS PM for Developer Oriented Testing, "the majority of the unit testing features of Team System" will be available in the Pro level SKU with the upcoming release of Visual Studio Orcas.

This is fantastic news because it will put XUnit style unit testing functionality in the hands of more .NET developers than ever before! In a sense, this moves XUnit functionality from leading edge to the mainstream. And, while I agree with Brad Wilson about moving the unit testing infrastructure into the .NET framework, this is still quite a significant accomplishment.

Congratulations to Naysawn and his team for responding to customer feedback and making this happen! And, congratulations to all those unsuspecting .NET developers out there on their impending XUnit enlightenment!

Off with a bang!

aridle — Fri, 29 Jul 2005 12:46:00 GMT

The two sessions I attended today were, for me, the best of the conference. Storytest-Driven Development with Max Baumann and Gil Broza was the best overview of Fit that I’ve yet encountered. And, Diana Larsen & Pollyanna Pixton were wonderful on Meeting the Agile Leadership Challenge.

Fit was a huge part of this conference. Ward & Rick talked about it on Sunday. Rick presented a tutorial on Tuesday (see below). It came up in virtually every single Testing track session I attended. There was a Fit Fest, where you could try your hand at it on a real project. All of this was great. But, today’s session with Max and Gil finally gave me the foundation to really feel comfortable writing my own Fit tests. More importantly, I finally understand why it is so important to use Fit. It was a major light bulb moment for me: Fit tests run directly against the business tier of an application rather than through the user interface. It does this in order to force the separation of the business logic from the presentation tier. In other words, Fit is a tool that, by its very nature, drives you toward lower coupling between the model and the view. (Thank you, Brian Marick, for that insight!)

I also had a huge light bulb moment in Diana & Pollyanna’s session: I need to reframe how I describe what I do. All week, I’ve been describing what the patterns & practices group does as “filling the gap” between customers’ immediate needs and product groups’ longer term plans. After explaining it 50 to 100 times, I was quite good at it. Unfortunately, I was using language that reinforced negative perceptions. Basically, if you’re looking for trouble, you’ll find it. But, if you’re looking for possibilities, you’ll find them, too.

There is a great book on framing called Don’t Think of an Elephant by George Lakoff. In it, the author describes how important framing is to getting across the message you want to send. For example, when you read the title of the book, what’s the first thing that comes to mind? An elephant, of course! It turns out that the human mind does not process negatives very well. Instead, it hears “think of an elephant” and immediately does so. Why? Because the frame including elephants gets activated in the brain. Diana had a spooky example of this in the session: “Don’t Drink and Drive.”

Note: The book is highly political, so it may not be for everyone. But, whether or not you agree with the author’s political positions, the discussion of framing is well worth the $10.

So, by talking about problems and gaps, I was reinforcing those frames rather than what I really wanted to communicate, which was this: Imagine what is possible, given the amazing and uniquely talented people on both sides of the patterns & practices group! Let’s find ways to collaborate – with customers and product teams – to turn those possibilities into reality.

Who is responsible for testing?

aridle — Wed, 27 Jul 2005 11:09:00 GMT

If I were to ask you, “Who is responsible for quality?” you’d likely answer, “Everyone.” But, if I were to ask you, “Who is responsible for testing?” would your answer be the same?

This afternoon I attended a tutorial session entitled Agile Testing for “Traditional” Testers and Agile Team Members hosted by Lisa Crispin and Anko Tijman. The goal of the session was to introduce non-agile testers and non-tester agilists to the concepts and techniques of agile testing. I took several things away from this session:

Everyone on an agile team is responsible for testing!
Yes, even the developers!
Yes, even the customer!
Everyone on the team is also responsible for test automation, as well.
Unit testing provides the highest return on investment in terms of lowering defect counts.
Acceptance testing just beneath the user interface provides the next highest return.
User interface testing, although brittle, can provide return in some situations.
Exploratory or context driven testing is commonly used on agile teams to leverage a tester’s knowledge of how things are likely to break.
Measuring progress can be as simple as counting your tests every day and plotting the numbers on a big, visible chart.

At the end of this session, Bart Hsu (of MSN) and I invited Lisa to come speak to a joint meeting of our respective user groups. As it turns out, Lisa has never been to Seattle. We’ll follow up with her after the conference to see if we can really make it happen. I’ll keep you posted – or, you can watch the Yahoo! mailing list for the Seattle XP group: extremeprogramming-seattle.

Mugridge on Fit

aridle — Tue, 26 Jul 2005 11:25:00 GMT

How could I pass up the opportunity to hear Rick Mugridge talk about Expressing Business Rules in Fit?

Um… What is Fit? And, who is Rick Mugridge?

Fit is an open-source framework for the automation of acceptance tests. And, Rick is a leading contributor to the Fit ecosystem. He’s also an Associate Professor of Computer Science at the University of Auckland and the co-author of Fit for Developing Software: Framework for Integrated Tests with Ward Cunningham.

I have not yet used Fit on a project. But, it is still on the top of my list of really cool things. Basically, you use Fit to capture software requirements as “story tests” in tables in Word documents. This allows you to document a conversation between the customer team and the development team. But, it also allows you to automate these tests and produce HTML output with red/green status indicators. The idea is to make the acceptance tests so easy to write that even the customer can do it.

That’s all well and good, but how do you automate a bunch of tables in a Word document? That’s where you (a developer or tester) come in: you write something called a fixture, which is really just an adapter between Fit and the object you want to test. The idea here is to get beneath the presentation layer and test the model directly.

I’d give you an example, but like I said, I haven’t used it yet. Check out the Fit site for more information. Odds are, there’s a port for your favorite language.