Summary of Writing Tests First in ATG

In early 2002, Classroom Connect began adopting XP practices when a new executive was brought in from Chrysler. A year later, most of the practices are in place.

They provided a quick overview of XP, focusing on pair programming, continuous integration, simplified code, user stories, and early involvement of the QA process. They ran through the development tools they use: Ant, JUnit, IntelliJ Idea, and most importantly, MockDynamo, a set of Dynamo mock objects that they are releasing on SourceForge.

They then addressed Test-First in ATG. They provided a quick description of Test-First, focusing on simpler code, tests as documentation, and test suites facilitating developer courage.

They were big fans of mock objects and described how using mocks had allowed their development team to defer database design until most of the application was developed. More importantly, the test-first cycle does not involve the application server, and therefore the server does not need to be restarted with every change. The server only needs to be running (and restarted) when browser verification is needed.

They did a walkthrough of their development process using their MVC architecture as a framework:

1. Develop the View (JSP)
2. Write test and implement Controller (Droplet or FormHandler)
3. Create MockService for the Controller test
4. Write tests and implement JavaBeans as needed
5. Verify View/Controller with Dynamo running (using MockService)
6. Repeat steps until all related use cases are complete
7. Write tests and implement Model (Service) using MockService as basis

During the birds of a feather session that evening, I was impressed with Christopher and Rodrigo's humility and still-learning stance.

They shared many of the initial mistakes they had made, which centered mostly on trying to mock too many ATG classes. After wrestling with this for a while, they gave up and tried to Do the Simplest Thing that Could Possibly Work and discovered it was far easier than they had originally thought to mock the neccessary Dynamo API. They discovered that they could let their tests tell them which Dynamo interfaces needed to be mocked simply by writing their tests as if they would run and following the failures in the stack trace to point them to the objects they needed to mock.

Additionally, they were surprised that some of the Dynamo classes they had assumed needed to have Dynamo running would work without it, for instance, RqlStatement.

They use mocks as a pointer for the next class to implement. For instance, when they are implementing a FormHandler, they will mock out a Service. Once the form handler is developed, they will implement the Service they had previously mocked out.

I spoke to them afterward about their planning process. They have user stories, though it sounds like the coaches give the initial estimates, backed by detailed "acceptance criteria" and use cases, and then the "engineers" provide estimates when they sign up for the stories during the iteration planning session. They reported that the planning process had been the most difficult piece of XP to adopt thus far.