SUnit Tests Asserting Morphic State
Last updated at 4:14 pm UTC on 14 January 2006
Colin Putney introduced me to this approach. To see and execute the full example, install BFAV2 and look at DecentReviewerNPTransferTest>>testReviewSteps. Note, this is a GUI test Of course we want to make most of our SUnit tests model tests.
Context: I want to ensure that a certain checkbox (actually an UpdatingThreePhaseButtonMorph) is "checked" according to the reviewSteps completed on the "to be transfered post" rather than on the "target post."
Approach: First, I will show how to set up the test to find and verify the checkbox and then I will describe some additional steps I needed to take to ensure that I get consistent results when running the test.
Following Colin, we set up methods:
- to find the relevant control (category morphic)
- to assert something about the relevant control (category asserting)
in addition to the usuall TestCase running and testing message categories.
We will start from the top. We code the (testing)methods:
testReviewSteps
self assertUpdatingThreePhaseButtonMorphIsOnFor: #togglePassesSLint.
Notice that this is not the assert: method that all TestCase's inherit from the SUnit framework, but rather one we have specifically created for testing the BVAF GUI. Is asserts that that the checkbox with the symbol #togglePassesSLint is "on", which is what it should be if I'm taking status from the correct place.
We implement this (asserting) method by reviewing the collection of such checklist as follows:
assertUpdatingThreePhaseButtonMorphIsOnFor: aSymbol
self updatingThreePhaseButtonMorphs
detect: [:each | each actionSelector = aSymbol and: [each isOn]]
ifNone: [self assert: false]
The way we pick a relevant checkbox is by using one of its attributes (actionSelector.) The way we confirm the check box is on is by using another accessor method. This type of code is specific to the particular morph being tested.
The assertion method delegates to the following (morphic)methods the task of collecting all of the checkboxes (3PhaseButtons):
updatingThreePhaseButtonMorphs
^ self morphsOfClass: UpdatingThreePhaseButtonMorph
morphsOfClass: aMorphClass
| morphs |
morphs := OrderedCollection new.
aDecentReviewerNotePad window
allMorphsDo: [:each | (each isKindOf: aMorphClass)
ifTrue: [morphs add: each]].
^ morphs
This is the approach used to find all submorphs of the DRNP's window that are of a particular class and to return them for inspection.
The above approach is used in a large number of BFAV and Monticello test cases. However, as shown here it often failed. I discovered two addtional things I needed to do to the testing methods to make it work. Here is the revised (testing) method:
testReviewSteps
aDecentReviewerNotePad window openInWorld.
Delay forMilliseconds: 500) wait.
self assertUpdatingThreePhaseButtonMorphIsOnFor: #togglePassesSLint.
Until I actually opened the DRNP window, the UpdatingThreePhaseButtonMorph never had a chance to set its state based on the underlying model and as a consequence the test always failed. Until I added the Delay statement, test behavior was very inconsistent, on any given run this test method might pass, fail or error. But when I went to debug the failures it looked right and when I went to debug the errors, I would get an Assertion failed Debug window. Without the delay, the 3PButton didn't always get a chance to step and set itself.
