Skip to content

Commit

Permalink
Merge pull request #4 from jordanmontt/feature/editing-ui-testing-cha…
Browse files Browse the repository at this point in the history
…pter

Feature/editing UI testing chapter
  • Loading branch information
Ducasse authored Jul 6, 2021
2 parents d20378a + 4b60e16 commit 4ed6104
Show file tree
Hide file tree
Showing 2 changed files with 83 additions and 49 deletions.
132 changes: 83 additions & 49 deletions Chapters/UITesting/UITesting.pillar
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ To help you understand the different possibilities of testing that you can engag
- ""Widget Developers."" Widget developers are concerned about the logic and working of a given widget is a given back-end.

%+UI elements under test.>file://figures/UI.png|width=75|label=fig:UI+
We will focus on the first role because it is simpler.
We will focus on the first role.
For the reader interested in the second role, the class ==SpAbstractBackendForTest== is a good starting place.

!!! Spec user perspective
Expand All @@ -39,74 +39,108 @@ Inversely when the user interface components change, we should ensure that the m

!!!! Example

%Figure @*fig:UI* shows the little application that we use in our example.
We will test a simple spec application. The model for this application can be any class.
It shows in a tree presenter all the subclasses of the model. Also, has a text presenter that shows the definition string for the selected class.
Finally, has a string morph and a button. When the button is
pressed, the colour of the morph changes randomly.

Here is a simple example: Imagine we have the following requirements.
- Click the button should add an element to the list.
- Select an element in the list should populate the form.
- Changing values in the form should change the objects in the list.
+A Spec application.>file://figures/example_spec_application.jpg|width=75|label=fig:SpecApp+

Such requirements are in fact the ones of the Pharo Launcher configuration list.
We convert such requirements into tests as follows:
!!!! Spec user test 1: the tool should be initialized correctly

!!!! Spec user test 1: triggering a button action
The tool will be instantiated with a model.
In this case, we will use ==Object== because it is the root of almost all classes.
So, when we instantiate the spec application of the figure above, all the sub presenters of the application must show the data of the model.

[[[
testInitialization

| model |
model := String.
spApplication := ClassVisualizerPresenter on: model.
self assert: spApplication model equals: model.
self
assert: spApplication textPresenter text
equals: model classDefinitions first definitionString.
self
assert: spApplication morphPresenter morph contents
equals: model name
]]]

Here we specify that clicking the button should add an element to the list.
The message ==launchConfigurations== is returning the list of configurations exposed by the launcher.
Therefore we store the number of list items, then we access the add button of the presenter (here named image)
and we click this button sending the message ==click==.
And we verify that the length of the list has increased by one.

!!!! Spec user test 2: when selecting a new item in the tree presenter the text presenter and the morph should change

The tree presenter shows a tree of classes.
When a class of the tree presenter is selected, the text presenter should change according to the definition of the new selected class.
The morph must change as well.

[[[
testClickAddButtonCreatesNewLaunchConfiguration

| old |
old := image launchConfigurations size.
editor addButton click.
self assert: image launchConfigurations size equals: old + 1
testSelectItemOnTreePresenter

"As we have initialized the tree with Object as its roots. The class OrderedCollection is a subclass of Object. We would simulate that a user selectes OrderedCollection from the tree presenter."

spApplication := ClassVisualizerPresenter on: Object.
spApplication hierarchyTreePresenter selectItem: OrderedCollection.
self
assert: spApplication hierarchyTreePresenter selectedItem
equals: OrderedCollection.
self
assert: spApplication textPresenter text
equals: OrderedCollection classDefinitions first definitionString.
self
assert: spApplication morphPresenter morph contents
equals: OrderedCollection name
]]]


!!!! Spec user test 2: changing text input
The following test verifies that a selection of an element in the list should populate the form.
The method ==clickItem:== simulates the selection of the element of index passed as argument.
!!!! Spec user test 3: triggering the button action

The action of the colour button changes the colour of the morph randomly.
When the button is clicked the morph must change its colour.

[[[
testClickOnLaunchConfigurationListItemSetsFormName
| name |
name := 'test'.
image addLaunchConfiguration: (PhLaunchConfiguration named: name).
editor refreshList.

editor configurationList clickItem: 3.
self assert: editor form nameInput text equals: name
testButtonChangesMorph

| previousColor |
spApplication := ClassVisualizerPresenter on: Object.
previousColor := spApplication morphPresenter morph color.
spApplication colorButton click.
self
deny: spApplication morphPresenter morph color
equals: previousColor
]]]


!!!! Spec user test 4: the text presenter should not be editable

!!!! Spec user test 3: checking list item displayed value
Changing values in the form should change the objects in the list.
This test selects the second item of the list so that the form displays the values
of such item.
Then the name displayed in the form editor is changed to a new text.
And using the message ==displayValueAt:==, it verifies that the displayed value of a given list item (here the second 2, the currently displayed in the form)
is actually the new entered text.
For this application, we only want that the text presenter shows the class definition.
We do not want the user to be able to edit it.

[[[
testEditConfigurationNameUpdatesListItem
| newName |
newName := 'some name'.
editor configurationList clickItem: 2.
editor form nameInput text: newName.

self
assert: (editor configurationList displayValueAt: 2)
equals: newName
testTextPresenterIsNotEditable

spApplication := ClassVisualizerPresenter on: Object.
self deny: spApplication textPresenter isEditable
]]]


These examples of tests show that key actions such as clicking on a button, changing text, selecting
a given list elements can be used to verify the expected behavior of the user interface.
!!!! Spec user test 5: the window is built correctly

Here, we will test that the title and the initial extent of the window are correct.
Also, we will test if the window were built correctly.

[[[
testInitializeWindow

| window |
spApplication := ClassVisualizerPresenter on: Object.
window := spApplication openWithSpec.
self assert: window isBuilt.
self assert: window title equals: ClassVisualizerPresenter title.
self assert: window initialExtent equals: 600 @ 400.
window close
]]]


!!!! Known limitations and conclusion

Expand Down
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 4ed6104

Please sign in to comment.