You bring up valid points.  However, if the position of data is in some
way business driven, you should test that it is in the proper place. 
For instance, I am working on a transplant information system that
displays lab data, evaluation data, national listing data, etc.  The
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.

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.

=jason

On Tue, 2003-08-05 at 13:11, Colin Putney wrote:
> 
> On Tuesday, August 5, 2003, at 09:26  AM, Jason Rogers wrote:
> 
> > I'll add my $.02 here.  I don't believe it's enough to test that 
> > certain
> > aspects appear somewhere within the GUI.  It's important that they
> > appear in the proper context.  In web pages you can assert that the
> > proper text/image/etc. appears in the correct cell of a table or that 
> > an
> > input field is in the right form, etc.
> 
> Yes, there are situations where those things could be important, but I 
> was surprised at how often they turn out not to be. Perhaps you're 
> presenting time-series data and you want to be sure that all the values 
> for the same series end up in the same row of the table. Ok, sure.
> 
> But most of the time, tables are just used for layout, and there are 
> many ways to arrange the cells for the same visual effect, and many 
> possible page designs that present the information intelligibly. If you 
> test for some specific layout, your tests are fragile.
> 
> The same applies to forms, although it's not quite as obvious. I'd 
> argue that the need to test details about how your forms will be 
> submitted is a sign that the UI is too tightly coupled to HTTP. Better 
> to separate out the networking stuff and test it in isolation.
> 
> Colin
> 
>