My intention in the first article here was to show how I try to think and program at the same time, so that all of analysis, design, coding, and testing happen “at once”. This was triggered by observing the participants in our Agile Skills Workshop spending lots of time in the Sprint just talking, and very little time actually building the product. It seems to me that it’s possible to do both, and actually quite desirable.

Today’s question is whether to do acceptance tests as part of my Ruby payroll series. A deeper question is whether I’m actually doing a Ruby payroll series. We’ll see about that as time goes on.

Discussing the topic were Bill Tozier, Nayan Hajratwala. Barb Tozier was keeping score, I think.

The primary purpose for acceptance tests is to improve communication between the customer / product owner and the team. Card, conversation, confirmation, you remember. If/when I do a long demonstration of incremental development based on payroll, that won’t be part of the demonstration: the point will be about how to build a product very incrementally, delivering “features” on a regular basis, while not painting oneself into a corner. So I don’t need acceptance tests for their primary purpose.

My immediate purpose for wanting access to the tests from our workshop was to get some of the tricky tests and values that drive out details. For example, there’s an early one that causes us to know that one ought not do financial calculations in floating point. I can serve that purpose by looking at our servers and reading the tests: I don’t need to run them in Fitnesse.

So I don’t need acceptance tests qua acceptance tests. That leaves open whether I’ll do better with Test::Unit or with rspec. If I use rspec, I’d learn better how to use it, which could be good. I like Test::Unit better, so probably I’ll stick with that. We’ll see.