Ui Driven Design

ModelFirst
Adopt a UI-driven architecture by Ash Rofail, jun 1999 at http://www.devx.com/upload/free/features/entdev/1999/06jun99/fe0699/fe0699.asp (October 2004: This link no longer works, and I couldn't find an alternative.)

My main questions are:

Do UnitTests favour stateful clients?
Could we treat the GUI as a functional test?
Should UserStory cover the GUI so it is apparent how to code UnitTests?
If UiDrivenDesign is a dead end, where did I go wrong?

In ModelFirst, the discussions seem to forget that creating the GUI is not an easy task. The conclusion is mainly that if you have well written code, then the GUI is easy to attach on top.

I do not agree with that. What is considered well written code depends on the context. How do we know what well written code is to the GUI if we leave it out? The GUI will finally have code which has needs. It is somewhat too late to let it tell us what those are after the unit tests are done, isn't it?

Also stateful and stateless clients will need different kinds of code.

The other day I was programming a shopping basket and did the regular test-first approach. I ended up with good looking code suiting the stateful very well, but was equally clumsy to my stateless application. My basket object ended up with keeping state when it needed not to, and retrieving persisted state just to do a stateless operation. My tests did not reflect the GUI's needs.

-- ThomasEyde

IMHO you'd avoid this kind of problem by concentrating on developing user stories, rather than back-end code. The user doesn't care about back-end processing, stateless vs. stateful servers etc. They only care about how they can interact with the shopping basket through the user interface.

Therefore, start with the first story and only develop the code to meet that requirement. This will result in a simple system with a small amount of UI code and a small amount of back-end code. Then extend the system to implement the next story, refactoring as necessary. Develop like this and you will notice any design mismatch between the UI and the backend earlier on in development and probably avoid it altogether.

Thank's for the feedback. Agreed, I could develop my stories better. I never saw the UserStories as a description on how the user reach his goal using the UI (enter text in this field, push that button...), and I am not quite at ease with this approach. You are correct in that the story doesn't care about statefullness and so on, but the UI certainly does. I am not ready to give up this UiDrivenDesign idea. Perhaps I should do user story, then ui (spike), UnitTest, back-end code, then finish up the ui code.

On personal projects I use a quick GUI (see EarlyPrototyping) as a user story. There are problems inherent in tacking on a GUI at the last minute, and at the same time there are often technical issues which arise due to the need to support the desired work flow for the user. I try to strike a balance between building what I might not need (ModelFirst), and overselling the app/wasting tome on GUI features which are uneeded at the end of the day (UiDrivenDesign), by making a very early mock version of the program. I get to check out how the application 'feels', explore possible error states/conflicts due to user interaction, and define the direction of the project. From there I can do my modeling with a clear eye to the needs of the GUI and look for improvements in the apps work flow, without being bound to having lots of GUI code slowing me down. -- AaronCumming?