Testing user interactions: the Spotter case study

Testing user interactions can be difficult, especially when the user interface relies on background processes.

An interesting case is Spotter. The interface resides in a dropdown and it relies on significant background processes: first for performing searches, and second for showing the selection preview.

To exemplify and test the interface, we use Scripter. Here is a scenario that is reasonably complicated:

— we start a Spotter, and the first item is selected — we hover over the first item in the second category — then we hover over the item Ok action — and then we click on the button

spotterElementOnStartSampleActOnSecondCandidateWithDefaultObjectActOn
	<gtExample>
	<return: #BlScripter>
	| scripter actOnEvents actOn actOnHandler |
	scripter := self spotterElementOnStartSample.

	actOnEvents := OrderedCollection new.
	actOnHandler := GtSpotterByScripterExamplesActOnHandler new
			actOnEvents: actOnEvents.

	scripter element spotter announcer weak
		when: GtSpotterObjectActOn
		send: #onActed:
		to: actOnHandler.

	scripter mouseMoveOverStep: [ :s | s id: GtSpotterCandidateElementId index: 2 ].

	scripter
		mouseMoveOverStep: [ :s | 
			s
				id: GtSpotterCandidateElementId index: 2;
				id: GtSpotterCandidateActOnButtonId ].

	scripter
		clickStep: [ :s | 
			s
				id: GtSpotterCandidateElementId index: 2;
				id: GtSpotterCandidateActOnButtonId ].

	self assert: actOnEvents size equals: 1.

	actOn := actOnEvents first.

	self assert: actOn isActedUpon equals: true.
	self assert: actOn spotterSearch title equals: 'Priority 20'.
	self assert: actOn spotterStep equals: scripter element spotter steps first.
	self assert: actOn rawObject equals: 20.
	self assert: actOn objectToSend equals: 20.
	self assert: actOn toolToSend class equals: GtInspectorTool.
	self assert: actOn toolToSend object equals: 20.

	^ scripter

Scripter not only allows us to express all this logic and to deal with the background behavior transparently, but it also provides a preview of the actions.

This allows us to go back and forth between the script and the preview to guide the actual testing scenario.