On Wednesday, August 6, 2003, at 05:13  AM, Jason Rogers wrote:

> 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.

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.

> 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.

Cheers,

Colin