GUI output testing

Jason Rogers jacaetevha at fast-mail.org
Thu Aug 7 11:47:19 UTC 2003


On Wed, 2003-08-06 at 20:58, Colin Putney wrote:
> > customers are very particular about the order in which things appear.
> > As a developer it doesn't matter much to me is Cyclosporine comes 
> > before
> > or after Tacrolimus, but they care.  It's a matter of contextual
> > relevance for every screen.
> 
> Ok, sure. If that's a real requirement from your users, then by all 
> means test to make sure that it's met. That sort of sounds like it  
> might be tied into the domain model more than the UI, so I might 
> consider handling it in the model and testing it there. But it might 
> well belong in the UI, if for example, the required order depended on 
> "where you are in the application." It's trivial to do that sort of 
> test by examining a DOM.

Nah... I'd still argue to keep it out of the domain model, but YMMV.

> 
> > About forms... I don't quite agree with the coupling.  I tend toward 
> > the
> > 3-tier architecture.  I isolate the business layer from the 
> > presentation
> > layer so that I can have more than one presentation layer accessing the
> > same business objects underneath.  It's often the case (at least in my
> > experience) that presentation layers very often cannot reuse the same
> > code.  A web client is quite different from a desktop client, but the
> > data underneath each doesn't need to be.
> 
> Yup, separating business logic from presentation is good. For the same 
> reason, separating network communication from presentation is also 
> good. If you do it  well, you can test your HTTP abstractions one 
> place, and concentrate your presentation tests on the details of 
> presentation, not HTTP.

Which is exactly what we are doing now.

=jason



More information about the Squeak-dev mailing list