Thursday, August 26, 2010

Fixture-free in the rain

I'll be presenting at Agile Vancouver in November on "Fixture-free Automated Acceptance Testing". This is a brief excerpt from a discussion that sparked the idea for the presentation:

Fixture-free is about exercising the System Under Test directly with a testing DSL like Fit or Slim (or whatever). It does require developer-tester collaboration because the System Under Test needs to expose classes and methods that are (a) testable and (b) named with ubiquitous language. (Otherwise it degenerates into trying to write code in a poor excuse for a programming language!). But once we have this, testers can do lots of stuff without additional developer help. For (a trivial) example, if we have a class Account with methods deposit, withdraw and balance, with fitSharp, with no fixture code, we can write:





In reality, 100% fixture-free is unlikely, but we can drastically reduce the need for fixtures and for developers to write fixture code for every test.

Monday, August 9, 2010

What Am I Missing?

So Agile2010 is underway this week and due to the eternal constraints of time and money, I'm not there. I'm catching some of the buzz vicariously via Twitter and starting to miss ... well, what am I missing?

Based on past experience, I know I would be enjoying myself if I was there. I know the intense and intimate gathering of the AAFTT group would fill my brain with ideas that would percolate throughout the year. I know the energy and passion of @unclebobmartin would be contagious. I know the wisdom of a seemingly off-hand comment by @RonJeffries would reveal itself to me about a week later. I know a session by @jbrains or @GeePawHill would make me realize, yet again, that my understanding of agile development is incomplete and there's still another layer of mastery for me to pursue.

Oops, that's right! Those last two didn't make it on to the program, did they? And not being there gives me a chance to reflect once more on what is in the program. Of course, there's some truth in the observation that it's not really about the program, it's about the people and the chance to reconnect with old friends and meet new ones. But I think that's really only true if you're there on a speaker's comp. If it's costing you $3000 to be there, there better be some damn good content in the program!

Let's go back to basics. What is absolutely essential for a successful agile project? From my developer-centric POV, it's good developers. I don't believe that agile only works with rock-star developers. But it only works with developers who are dedicated to the concept of the software craft - that we are professionals and we work every day to hone our craft. This means working continuously to improve our understanding of SOLID, TDD and clean code. These aren't skills that you master in a 3 hour tutorial. These are skills you develop throughout an entire career.

What do I see dominating the Agile2010 program? Lots of good sessions on learning, communicating, coaching, creativity, adoption strategies. Sessions that I would probably come out of saying "interesting" and "thought-provoking". But ultimately, sessions that were easy to digest. Not sessions where I encountered concepts that are fundamentally difficult and require hard work to master. Not sessions where I struggled to write good tests and emerged with a determination to rework and discuss the examples over the coming weeks until I finally felt I understood it.

Perhaps I'm a minority. @HackerChick tweeted about a tutorial on TDD where only a quarter of the attendees showed up with laptops, prepared to get their hands dirty. Perhaps Agile2010 isn't the conference for me. A conference where the technical track is only 1/15 of the program. And the technical track includes sessions on "The Butterfly Effect" and how to "Walk and Code". But I worry about another crop of agile converts, filled with all the soft skills and strategies they need to succeed, headed for failure because they don't know about the hard work and dedication needed to build that essential ingredient: the agile developer.