We have some cool matchers (Phexample, StateSpecs), some nice mocking
libraries (Mocketry, BabyMock), and Phexample's acknowledgement that tests
build on each other. The problem is, it's hard to cherry-pick and build
one's perfect test enviroment. For example:
- Phexample and Mocketry, whose matching frameworks break each other
- Phexample and BabyMock both require subclassing from their own TestCase
subclass, so they can't be used together.
I wonder what the solution is? Maybe some registration scheme? It'd be nice
to be more coordinated here. As a first step, I manually merged BabyMock and
Phexample to produce the following (IMHO) gorgeous tests...
testNew
self library should
receive: #FMOD_System_Create:;
with: FMOD_SYSTEM new;
does: [ :h |
h handle: 20.
0 ].
self library should
receive: #FMOD_System_Init:;
with: [ :a | a handle = 30 ];
answers: 0.
^ FmodSystem new.
testNewSound
| soundFile system |
system := self given: #testNew.
soundFile := FileLocator vmBinary.
self library should
receive: #FMOD_System_CreateSound:to:with:;
with: soundFile fullName and: FMOD_SOUND new and: [ :h | h =
system handle
];
answers: 0.
^ system newSoundFromFile: soundFile.
testPlaySound
| sound |
sound := self given: #testNewSound.
self library should
receive: #FMOD_System:PlaySound:on:;
with: sound system handle and: sound handle and: FmodChannel
new;
answers: 0.
^ sound play.
testChannelIsPlaying
| channel |
channel := self given: #testPlaySound.
self library should
receive: #FMOD_Channel_IsPlaying:storeIn:;
with: channel and: NBExternalAddress new;
does: [ :c :isPlaying | isPlaying value: 1 ].
^ channel isPlaying.
The tests... let's call them specifications... clearly state how the object
should talk to the FMOD library. The neat part of Phexample is that even
though each specification uses the result of the last, it's smart enough not
to fail the dependent if the #given: fails. It moves it into "expected
failures" this is important because otherwise a failure deep in the system
would make it difficult to pinpoint since there could be many failing
specifications.
n.b. in this case, I'm not sure that mocking is the best strategy and I may
end up using a hand-written stub, but I wanted to do a case study. One area
where I've really found mocks to shine is internal to one's system. That is,
I'm writing an object and discover that it must talk to another
as-yet-unwritten object. So I mock it out and in so doing define its API,
which I then go implement. Also, the mocks are using a custom extension to
BabyMock that allows you to pass the arguments do #does:, so it will not run
on vanilla BabyMock
-----
Cheers,
Sean
--
View this message in context:
http://forum.world.st/Unifying-Testing-Ideas-tp4726787.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
