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!
Liz Keogh, lunivore 
This kind of post reminds me why I miss working at ThoughtWorks!
Happily, I should soon be back on an agile project.
if u like your domain objects to look like screens then this is good. Especially with novice pairs, your domain entities will end up having a 1 to 1 relationship with sceens each with a getter that matches a field on the screen.
Better to drive out the domain through fit story tests or TDD or BDD whatever, along the way there will be lots of questions and issues, constantly verify naming of objects with the customer. Show the customer a sketch of your “model” and get feedback. Now test drive the controller logic of your potential UI with this domain. Finally wire the thing up to your screens and db (of course this is the hard part because if you use hibernate and jsf etc. you’ll end up poluting your domain so these tools can get at your data)..
Good Post. This is similar to the Test first Development, may be call it Screen first Domain.
I would be interested to know whether F2B development is faster than B2F.
Any ideas?
I’ve used the front-end first approach with both Web and Swing front-ends now, with great success. I guess it depends how complex the screens are. The two projects on which this approach has been most powerful both had highly aesthetic requirements for the front end (which in part were responsible for the automated testing difficulties). We also find that having prototypes of the front-end, whether on paper or screen, helps us to drive conversations about the domain.
It definitely doesn’t replace the conversations we have about the domain, and we’re doing BDD at a unit level. The controller still forms the boundary between the screen and the domain objects (with services between for complex interactions); I just change the order in which screen and controller are created.
I find it so, but it requires a shift in thinking similar to that used in TDD. You have to be happy to concentrate on the value that will come out of the code, and leave concerns about the underlying implementation till they need to be addressed.
I guess that if you find TDD faster than testing after the code is written then you’ll probably find F2B faster too.