John Overbaugh wrote:

> Presentation layer: we have a lot of cookie, session, view state and
> Ajax code in our presentation level. Apparently this is rather brittle
> code which means we've frequently broken stuff in the past. My dev and I
> have been discussing this, and the impact of a cookie or session change
> has been far-reaching and surprising. So we're wondering if there's a
> way to cover this stuff in a unit test - after all, this is code written
> by developer, it ought to be unit tested but that's the challenge we're
> grappling with. The challenge, of course, is that we're talking about
> unit tests which require interaction with a web server.

Here's a metaphor - the Golden Spike at Promontory Point, Utah, where the Union
Pacific and Central Pacific railways met for our first intercontinental
railroad.

A test through the browser is like driving a train all the way from St Louis to
San Fransisco.

Two unit tests are like driving all the way from one city to the golden spike.

To unit test, you don't need to test that a variable went into a session, went
into a cookie, came out in an action, went into JavaScript, went into Ajax, and
went into the browser.

You need to unit test each of those steps - even sinking as low as using
assert_match to spot-check that a variable showed up in some string.

Yet each unit test must reach just a little into the next layer. Otherwise, your
tests might not detect if you have two railroads that don't meet at Promontory
Point...

--
Phlip