Session 6

Unit Testing ... Toward a Project

810:188

Agile Software Development

On PLoP 2004

(Recognize anyone in that little banner picture?)

Short report related to the course:

• Gerard Meszaros's draft chapters on test-driven development and automating the testing process
  ... see http://testautomationpatterns.com/
• agile and XP, taken for granted in many places now ... spread across the world
• the original wiki and Ward ... social software, wide thinking, humility
• XML processing ... focus group, book in progress, use in:
• content management for writing and publishing books, blogs, wikis, other web sites, and so on ...

I even made my recent acting debut on Friday night, in a skit on introducing new ideas into an organization. The new idea used in the skit as an illustration? Agile software development! I was an obvious choice as the Early Adopter, a cautious decision maker who is open to change.

My lines:

Evangelist: Hey, Alice, I hear that you're working on the Ventures Project and I'm wondering if the <Agile Development> idea I presented in the Brown Bag seminar might be able to help you.

Early Adopter: Yes, I attended the Brown Bag, and I admit that it does sound interesting. But I want to hear more about practical application before jumping in feet first.

Evangelist: Okay, I know you have a lot of concerns, but you sound interested enough to try it out. Try it on the Ventures project for six months and see how it goes. If you don't like it, you can go back to the development ways you are using now. I'll help you keep an eye on things and we'll evaluate how it is going along the way.

Early Adopter: [rubbing chin slowly] Hmmmm, six months. Yes, I think we can do that. [shake hands]

I added the chin rub. I just felt that's what my character would do in the situation. I'm a natural!

Revisiting Homework 1

[ Answer the following with partners, with another, with whole group. ]

Easiest part of assignment? Hardest?

• content: Nim game
• process: test-driven development and pair programming
• writing tests

On content: No complaints.

On the process:

• This is a student quote from e-mail: "We have most of the game working, and a few JUnit tests running." ... If you don't have tests, then you don't have code! What you have doesn't count, because we can't count on it.

• Both pair programming and test-driven development require a learning curve, during which you get used to the rhythm of designing and coding in a new way. Stick with it for a while; your comfort level will rise and you'll at least have a chance to experience the benefits.

On writing tests:

• "We figured out our solution and then had trouble writing the test..." Try writing the test first. *That* lets you focus on the goal, in terms of what you can test, and then turn to implementation. Writing tests first forced you to think in more direct terms.

• "Almost all of them were difficult." That's because many methods are void. Many of those do output to the screen. Input and output generally cause problems. What can we do?

  Separate the model from the view! This is a standard design pattern: Model-View. [I gave an example of a display method in class.] If you are at a point where your code mingles model and view, then you may want to refactor toward this pattern.

Toward a Class Project

[ I didn't say much about this in class, other than to describe the task at the highest of levels, and pointed you to the readings for next session. ]

Wrap Up

• Reading -- Read on project planning in two papers by Bill Wake: Agile Project Management, XP Style and Simplified Iteration Planning.

• Class -- In the lab for next session, and all remaining Thursdays.