David Shaffer on testing Seaside components. David's been doing a fair bit of Seaside work, and teaches Smalltalk at Westminster University. He and his students do a lot of Seaside work. Small aside here - there's a lot of Squeak/Seaside at this conference, especially in comparison to June's Smalltalk Solutions.

Some of what's up in Seaside testing:

• Tests run on the server (i.e., access to the tested component)
• Uses the Smalltalk debugger
• Web test runner
• Available for Squeak and VisualWorks (hat tip to Cincom's Michel Bany for the port)

Provides a test harness with a simulated web browser environment. You render the component into the harness. Setting up:

testComponent1
	self newApplicationWithRootClass: SCTestComponent1.
	self establishSession.
	self assert: (self lastResponse stringWithId: 'main') = 'hello'.

The nice thing here - you don't need to drive the web app to a specific point - you can do actual unit/component level testing. You can follow anchors this way, and then make assertions (as in normal unit testing) about where you should be and what state you should be in. The simulated browser environment hands back an XHTML DOM (XMLElement). The framework provides convenience methods for extracting useful bits.

Side point from me - it seems to me that you could combine this with WithStyle to provide a more visual unit testing framework - and they have a whole lot of useful code for dealing with XML.

So what can be tested?

• State - often tests of state are less brittle than display tests
• answer - components that provide a Seaside answer
• callbacks - components that provide hooks

For Seaside, you need to be able to backtrack, and the framework handles that as well. Other possible topics:

• Sessions are accessible
• There are hooks for configuring applications
• The history in the web test runner is "live"
• Marking interactions for visual inspection (so that you can look at the actual output later - important for GUI level examination. Note - framework masks self as Mozilla).
• David's site

Not tested - visual appearances, although snapshots (see above) can be saved. JavaScript not fully supported, but working with a JavaScript test framework (Selenium) for that. He would like to make the APIs consistent so that test cases could move back and forth. Other frameworks:

• SmallHttpUnit - VW, runs outside the server, excellent API for accessing page elements
• HttpUnit - Java, external as well
• Cactus - runs in server (Java) like HttpUnit
• Struts has a framework as well

Question - would using WS or Twoflower for display help? Not so much. Having a "is it basically right (visually)" would be nice, but most visual issues are on the order of "looks ok in Mozilla, it's screwed in IE" sort of problem ("up level experience" notwithstanding).