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
|