Interface driven design and testing
The Object Mentor website has an excellent article on testing and the primary role acceptance tests. The part that I found the most interesting resonates with something I have been thinking about lately; when should acceptance tests be written.
Acceptance tests should be written at the start of each iteration. QA and Business analysts should take the stories chosen during the planning meeting, and turn them into automated acceptance tests written in FitNesse, or Selenium or some other appropriate automation tool.
The first few acceptance tests should arrive within a day of the planning meeting. More should arrive each day thereafter. They should all be complete by the midpoint of the iteration. If they aren’t, then some developers should change hats and help the business people finish writing the acceptance tests.
If the creation of an application is driven from its interface (those designs and wireframes that Usability people create), then both the developers and the QA people are working from the same page. It should be easy to create a series of Selenium tests that ensure the application is following the interface.
If a problem is found, then it is the interface that needs to change and the code and Selenium tests respond to that change. This helps ensure the client is getting what they envisioned.
I am not a fan of Big Design Up Front, but I think when it comes to applications that will be used by people, no matter who those people are, then it is the interface, or GUI, used by those people that needs to drive the development.
The thing I find cool about creating acceptance tests immediately is that it provides an independent check on what the developers are doing. It also provides a clear path for the developers to follow in creating the application. If you can clearly see what the inputs and outputs are, it is easier to code against them. It also shows you when you are done. If all the tests pass, then that story is complete; time to move on to the next one.
While a lot of agilists look at a UI prototype as a forbidden “design up front”. I think it is an invaluable tool to help lower risk and provide immediate feedback for an important part of the project.
The prototype doesn’t have to include all the functionality – but it has to deliver the spirit of using the system. The prototype can also evolve screen by screen (and sometimes feature by feature) as the project progresses and in my experience this always customers and end-users love the interaction and their ability to help shape the direction the application they use later
After mocking objects in my unit tests with Ruby, I’ve found that it is imperative that integration/acceptance tests be created. Especially if using events to drive the application.