Liz Keogh's blog

How do you use tests to drive well-designed code, when you’re not able to write automated acceptance tests?

Sometimes we do this, whether there are automated tests or not:

• Write some code that gets accesses the database (and turns the data into domain objects).
• Write some code that gets the useful information from the domain objects.
• Write some code that talks to the front end.
• Write the front end.
• Demo the result and get feedback (and hopefully sign off the story).

There’s nothing wrong with this, and it usually works! But here’s another way:

• Write the front end, but keep the buttons and boxes empty.
• Demo the result and get feedback.
• Write the code that talks to the front end. Hard-code or mock some information to check that it works.
• Demo the result and get feedback.
• Write the code that uses the domain objects to get the values. Build fake domain objects. Check that it looks exactly the same as it did in the demo.
• Write the code that accesses the database.
• Demo the result and get feedback (and hopefully sign off the story).

What are the benefits of doing front-end to back-end, instead of back-to-front?

• Quick feedback! Always good.
• QAs can look at the front end, imagine how it will interact with the rest of the system, and write more accurate test plans.
• You will never write code that you don’t need, because there will always be a customer or some other code that needs it.
• When you swap pairs, it’s easier to show your new pair how far you’ve got, and what still needs to be done.
• You don’t have to design every part of the story in your head before you start coding – just do it!