Reusing & Composing
Tests with Traits
Stéphane Ducasse RMod Inria Lille Nord Europe
& University of Lille 1
Damien Pollet
Alexandre Bergel
Damien Cassou Phoenix University of Bordeaux 1

Motivation redesigning the Smalltalk collections
Problem few tests, similar protocols
Case study can we benefit from traits in tests?
Results write one test, 4 for free
Perspective even more reuse!

Smalltalk collections
Object
Collection
SequenceableCollection Bag
Set
LinkedList PluggableSet
Interval
ArrayedCollection Dictionary
OrderedCollection
Array String Text IdentityDictionary
SortedCollection
ByteString Symbol PluggableDictionary

Smalltalk collections
Rich, versatile library
Dynamic typing: “if it quacks like a duck…”
highly polymorphic
many common protocols
pluggable behaviors

Common Protocols
accessing size capacity at: at:put:
isEmpty occurrencesOf:
testing includes: contains:
adding, add: addAll:
removing remove: removeAll: remove:ifAbsent:
do: collect: select: reject:
enumerating inject:into: detect: detect:ifNone:
asBag asSet asArray asOrderedCollection
converting asSortedCollection asSortedCollection:
creating with: withAll:

Existing Tests
“Test-by-Use™”
No systematic testing
:(
features
limit conditions
Duplicated test methods
Tests for ad hoc behavior

Photo from http://www.flickr.com/photos/cobalt/ (Creative Commons BY-NC-SA 2.0)

Hypothesis
A protocol should:
behave similarly across its implementors
thus, be testable by similar code
But: one test class = one fixture
fixture reuse => multiple inheritance

Other Approaches
TestCase
Inheritance-based (xUnit)
PutTest
PutTest
superclass provides test methods PutTest
PutTest
testAtPut
testAtPut
… testAtPut
… testAtPut
…
subclasses provide fixtures …
:(
OrdCollPutTest
OrdCollPutTest
OrdCollPutTest
OrdCollPutTest
empty
empty
… empty
… empty
……
Parameterization (JUnit 4)
fixture classes, passed to the tests
impractical to adapt TestCase
OrdCollFixture
OrdCollPutTest
OrdCollPutTest
:(
PutTest OrdCollPutTest
empty
PutTest empty
empty
… empty
PutTest
testAtPut
PutTest ……
testAtPut
testAtPut
… testAtPut …
………

Quick Primer on Traits
Classes are schizophrenic!
units of creation vs. units of reuse
Traits: Units of composable behavior (no state)
multiple implementation inheritance
composer is in control
resolve conflicts via ignore / alias
able
E.g.: Magn itude, or Ruby’s Compar
lation,
given the total order re
arison operators ≤, <, >, ≥
…
provide the comp

Superclass
+ State
Class = + Traits
+ Glue Methods
Object
Component Geometric
RectangleWidget TColor RectangleShape
x1, y1, x2, y2 TRectangle point1, point2
setX1(...) setX1(...)
setY1(...) setY1(...)

Test Traits
Photo from http://www.flickr.com/photos/cobalt/ (Creative Commons BY-NC-SA 2.0)

Test Traits
One test trait per protocol
requires accessors to a fixture
provides systematic domain-level tests
Test classes
compose test traits
define the fixture
define additional specific tests
Superclass (TestCase)
+ fixture
Test Class = + test traits
+ glue methods

TPutTest >> testAtPut
self nonEmpty at: self anIndex put: self aValue.
self assert:
(self nonEmpty at: self anIndex) == self aValue.
TPutTest >> testAtPutOutOfBounds
self
should: [self empty at: self anIndex put: self aValue]
raise: Error.
TPutTest >> testAtPutTwoValues
self nonEmpty at: self anIndex put: self aValue.
self nonEmpty at: self anIndex put: self anotherValue.
self assert:
(self nonEmpty at: self anIndex) == self anotherValue.

For TPutTest, the fixture must provide:
empty nonEmpty: instances of the collection
anIndex: integer or dictionary key or…
aValue anotherValue: legal for the collection
Each test class:
controls which test traits to compose (and how)
provides ad-hoc tests
:)
groups all test code for a domain class

Results
27 test traits
150 tests written
29 fixture req.
test runner reports:
765 runs

Results
One test written, ~4.7 run
:)
average on a wide subset of the collections classes
still 1.8 / 1 when counting all methods
Balances to strike:
tests & fixtures: explicit vs. generic
inheritance, pre-composed traits…

Test Traits
More extensive tests
more classes => further reuse
Identified protocol (a)symmetries
inter-dialect standard
insight for future redesign
http://pharo-project.org