| 1 |
lars |
1 |
<html>
|
|
|
2 |
<head>
|
|
|
3 |
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|
|
4 |
<title>SimpleTest for PHP mock objects documentation</title>
|
|
|
5 |
<link rel="stylesheet" type="text/css" href="docs.css" title="Styles">
|
|
|
6 |
</head>
|
|
|
7 |
<body>
|
|
|
8 |
<div class="menu_back">
|
|
|
9 |
<div class="menu">
|
|
|
10 |
<h2>
|
|
|
11 |
<a href="index.html">SimpleTest</a>
|
|
|
12 |
</h2>
|
|
|
13 |
<ul>
|
|
|
14 |
<li>
|
|
|
15 |
<a href="overview.html">Overview</a>
|
|
|
16 |
</li>
|
|
|
17 |
<li>
|
|
|
18 |
<a href="unit_test_documentation.html">Unit tester</a>
|
|
|
19 |
</li>
|
|
|
20 |
<li>
|
|
|
21 |
<a href="group_test_documentation.html">Group tests</a>
|
|
|
22 |
</li>
|
|
|
23 |
<li>
|
|
|
24 |
<span class="chosen">Mock objects</span>
|
|
|
25 |
</li>
|
|
|
26 |
<li>
|
|
|
27 |
<a href="partial_mocks_documentation.html">Partial mocks</a>
|
|
|
28 |
</li>
|
|
|
29 |
<li>
|
|
|
30 |
<a href="reporter_documentation.html">Reporting</a>
|
|
|
31 |
</li>
|
|
|
32 |
<li>
|
|
|
33 |
<a href="expectation_documentation.html">Expectations</a>
|
|
|
34 |
</li>
|
|
|
35 |
<li>
|
|
|
36 |
<a href="web_tester_documentation.html">Web tester</a>
|
|
|
37 |
</li>
|
|
|
38 |
<li>
|
|
|
39 |
<a href="form_testing_documentation.html">Testing forms</a>
|
|
|
40 |
</li>
|
|
|
41 |
<li>
|
|
|
42 |
<a href="authentication_documentation.html">Authentication</a>
|
|
|
43 |
</li>
|
|
|
44 |
<li>
|
|
|
45 |
<a href="browser_documentation.html">Scriptable browser</a>
|
|
|
46 |
</li>
|
|
|
47 |
</ul>
|
|
|
48 |
</div>
|
|
|
49 |
</div>
|
|
|
50 |
<h1>Mock objects documentation</h1>
|
|
|
51 |
<div class="content">
|
|
|
52 |
<p>
|
|
|
53 |
<a class="target" name="what">
|
|
|
54 |
<h2>What are mock objects?</h2>
|
|
|
55 |
</a>
|
|
|
56 |
</p>
|
|
|
57 |
<p>
|
|
|
58 |
Mock objects have two roles during a test case: actor and critic.
|
|
|
59 |
</p>
|
|
|
60 |
<p>
|
|
|
61 |
The actor behaviour is to simulate objects that are difficult to
|
|
|
62 |
set up or time consuming to set up for a test.
|
|
|
63 |
The classic example is a database connection.
|
|
|
64 |
Setting up a test database at the start of each test would slow
|
|
|
65 |
testing to a crawl and would require the installation of the
|
|
|
66 |
database engine and test data on the test machine.
|
|
|
67 |
If we can simulate the connection and return data of our
|
|
|
68 |
choosing we not only win on the pragmatics of testing, but can
|
|
|
69 |
also feed our code spurious data to see how it responds.
|
|
|
70 |
We can simulate databases being down or other extremes
|
|
|
71 |
without having to create a broken database for real.
|
|
|
72 |
In other words, we get greater control of the test environment.
|
|
|
73 |
</p>
|
|
|
74 |
<p>
|
|
|
75 |
If mock objects only behaved as actors they would simply be
|
|
|
76 |
known as server stubs.
|
|
|
77 |
This was originally a pattern named by Robert Binder (Testing
|
|
|
78 |
object-oriented systems: models, patterns, and tools,
|
|
|
79 |
Addison-Wesley) in 1999.
|
|
|
80 |
</p>
|
|
|
81 |
<p>
|
|
|
82 |
A server stub is a simulation of an object or component.
|
|
|
83 |
It should exactly replace a component in a system for test
|
|
|
84 |
or prototyping purposes, but remain lightweight.
|
|
|
85 |
This allows tests to run more quickly, or if the simulated
|
|
|
86 |
class has not been written, to run at all.
|
|
|
87 |
</p>
|
|
|
88 |
<p>
|
|
|
89 |
However, the mock objects not only play a part (by supplying chosen
|
|
|
90 |
return values on demand) they are also sensitive to the
|
|
|
91 |
messages sent to them (via expectations).
|
|
|
92 |
By setting expected parameters for a method call they act
|
|
|
93 |
as a guard that the calls upon them are made correctly.
|
|
|
94 |
If expectations are not met they save us the effort of
|
|
|
95 |
writing a failed test assertion by performing that duty on our
|
|
|
96 |
behalf.
|
|
|
97 |
</p>
|
|
|
98 |
<p>
|
|
|
99 |
In the case of an imaginary database connection they can
|
|
|
100 |
test that the query, say SQL, was correctly formed by
|
|
|
101 |
the object that is using the connection.
|
|
|
102 |
Set them up with fairly tight expectations and you will
|
|
|
103 |
hardly need manual assertions at all.
|
|
|
104 |
</p>
|
|
|
105 |
|
|
|
106 |
<p>
|
|
|
107 |
<a class="target" name="creation">
|
|
|
108 |
<h2>Creating mock objects</h2>
|
|
|
109 |
</a>
|
|
|
110 |
</p>
|
|
|
111 |
<p>
|
|
|
112 |
In the same way that we create server stubs, all we need is an
|
|
|
113 |
existing class, say a database connection that looks like this...
|
|
|
114 |
<pre>
|
|
|
115 |
<strong>class DatabaseConnection {
|
|
|
116 |
function DatabaseConnection() {
|
|
|
117 |
}
|
|
|
118 |
|
|
|
119 |
function query() {
|
|
|
120 |
}
|
|
|
121 |
|
|
|
122 |
function selectQuery() {
|
|
|
123 |
}
|
|
|
124 |
}</strong>
|
|
|
125 |
</pre>
|
|
|
126 |
The class does not need to have been implemented yet.
|
|
|
127 |
To create a mock version of the class we need to include the
|
|
|
128 |
mock object library and run the generator...
|
|
|
129 |
<pre>
|
|
|
130 |
<strong>require_once('simpletest/unit_tester.php');
|
|
|
131 |
require_once('simpletest/mock_objects.php');
|
|
|
132 |
require_once('database_connection.php');
|
|
|
133 |
|
|
|
134 |
Mock::generate('DatabaseConnection');</strong>
|
|
|
135 |
</pre>
|
|
|
136 |
This generates a clone class called
|
|
|
137 |
<span class="new_code">MockDatabaseConnection</span>.
|
|
|
138 |
We can now create instances of the new class within
|
|
|
139 |
our test case...
|
|
|
140 |
<pre>
|
|
|
141 |
require_once('simpletest/unit_tester.php');
|
|
|
142 |
require_once('simpletest/mock_objects.php');
|
|
|
143 |
require_once('database_connection.php');
|
|
|
144 |
|
|
|
145 |
Mock::generate('DatabaseConnection');
|
|
|
146 |
<strong>
|
|
|
147 |
class MyTestCase extends UnitTestCase {
|
|
|
148 |
|
|
|
149 |
function testSomething() {
|
|
|
150 |
$connection = &new MockDatabaseConnection();
|
|
|
151 |
}
|
|
|
152 |
}</strong>
|
|
|
153 |
</pre>
|
|
|
154 |
Unlike the generated stubs the mock constructor needs a reference
|
|
|
155 |
to the test case so that it can dispatch passes and failures while
|
|
|
156 |
checking its expectations.
|
|
|
157 |
This means that mock objects can only be used within test cases.
|
|
|
158 |
Despite this their extra power means that stubs are hardly ever used
|
|
|
159 |
if mocks are available.
|
|
|
160 |
</p>
|
|
|
161 |
<p>
|
|
|
162 |
<a class="target" name="stub">
|
|
|
163 |
<h2>Mocks as actors</h2>
|
|
|
164 |
</a>
|
|
|
165 |
</p>
|
|
|
166 |
<p>
|
|
|
167 |
The mock version of a class has all the methods of the original,
|
|
|
168 |
so that operations like
|
|
|
169 |
<span class="new_code">$connection->query()</span> are still
|
|
|
170 |
legal.
|
|
|
171 |
The return value will be <span class="new_code">null</span>,
|
|
|
172 |
but we can change that with...
|
|
|
173 |
<pre>
|
|
|
174 |
<strong>$connection->setReturnValue('query', 37)</strong>
|
|
|
175 |
</pre>
|
|
|
176 |
Now every time we call
|
|
|
177 |
<span class="new_code">$connection->query()</span> we get
|
|
|
178 |
the result of 37.
|
|
|
179 |
We can set the return value to anything, say a hash of
|
|
|
180 |
imaginary database results or a list of persistent objects.
|
|
|
181 |
Parameters are irrelevant here, we always get the same
|
|
|
182 |
values back each time once they have been set up this way.
|
|
|
183 |
That may not sound like a convincing replica of a
|
|
|
184 |
database connection, but for the half a dozen lines of
|
|
|
185 |
a test method it is usually all you need.
|
|
|
186 |
</p>
|
|
|
187 |
<p>
|
|
|
188 |
We can also add extra methods to the mock when generating it
|
|
|
189 |
and choose our own class name...
|
|
|
190 |
<pre>
|
|
|
191 |
<strong>Mock::generate('DatabaseConnection', 'MyMockDatabaseConnection', array('setOptions'));</strong>
|
|
|
192 |
</pre>
|
|
|
193 |
Here the mock will behave as if the <span class="new_code">setOptions()</span>
|
|
|
194 |
existed in the original class.
|
|
|
195 |
This is handy if a class has used the PHP <span class="new_code">overload()</span>
|
|
|
196 |
mechanism to add dynamic methods.
|
|
|
197 |
You can create a special mock to simulate this situation.
|
|
|
198 |
</p>
|
|
|
199 |
<p>
|
|
|
200 |
Things aren't always that simple though.
|
|
|
201 |
One common problem is iterators, where constantly returning
|
|
|
202 |
the same value could cause an endless loop in the object
|
|
|
203 |
being tested.
|
|
|
204 |
For these we need to set up sequences of values.
|
|
|
205 |
Let's say we have a simple iterator that looks like this...
|
|
|
206 |
<pre>
|
|
|
207 |
class Iterator {
|
|
|
208 |
function Iterator() {
|
|
|
209 |
}
|
|
|
210 |
|
|
|
211 |
function next() {
|
|
|
212 |
}
|
|
|
213 |
}
|
|
|
214 |
</pre>
|
|
|
215 |
This is about the simplest iterator you could have.
|
|
|
216 |
Assuming that this iterator only returns text until it
|
|
|
217 |
reaches the end, when it returns false, we can simulate it
|
|
|
218 |
with...
|
|
|
219 |
<pre>
|
|
|
220 |
Mock::generate('Iterator');
|
|
|
221 |
|
|
|
222 |
class IteratorTest extends UnitTestCase() {
|
|
|
223 |
|
|
|
224 |
function testASequence() {<strong>
|
|
|
225 |
$iterator = &new MockIterator();
|
|
|
226 |
$iterator->setReturnValue('next', false);
|
|
|
227 |
$iterator->setReturnValueAt(0, 'next', 'First string');
|
|
|
228 |
$iterator->setReturnValueAt(1, 'next', 'Second string');</strong>
|
|
|
229 |
...
|
|
|
230 |
}
|
|
|
231 |
}
|
|
|
232 |
</pre>
|
|
|
233 |
When <span class="new_code">next()</span> is called on the
|
|
|
234 |
mock iterator it will first return "First string",
|
|
|
235 |
on the second call "Second string" will be returned
|
|
|
236 |
and on any other call <span class="new_code">false</span> will
|
|
|
237 |
be returned.
|
|
|
238 |
The sequenced return values take precedence over the constant
|
|
|
239 |
return value.
|
|
|
240 |
The constant one is a kind of default if you like.
|
|
|
241 |
</p>
|
|
|
242 |
<p>
|
|
|
243 |
Another tricky situation is an overloaded
|
|
|
244 |
<span class="new_code">get()</span> operation.
|
|
|
245 |
An example of this is an information holder with name/value pairs.
|
|
|
246 |
Say we have a configuration class like...
|
|
|
247 |
<pre>
|
|
|
248 |
class Configuration {
|
|
|
249 |
function Configuration() {
|
|
|
250 |
}
|
|
|
251 |
|
|
|
252 |
function getValue($key) {
|
|
|
253 |
}
|
|
|
254 |
}
|
|
|
255 |
</pre>
|
|
|
256 |
This is a classic situation for using mock objects as
|
|
|
257 |
actual configuration will vary from machine to machine,
|
|
|
258 |
hardly helping the reliability of our tests if we use it
|
|
|
259 |
directly.
|
|
|
260 |
The problem though is that all the data comes through the
|
|
|
261 |
<span class="new_code">getValue()</span> method and yet
|
|
|
262 |
we want different results for different keys.
|
|
|
263 |
Luckily the mocks have a filter system...
|
|
|
264 |
<pre>
|
|
|
265 |
<strong>$config = &new MockConfiguration();
|
|
|
266 |
$config->setReturnValue('getValue', 'primary', array('db_host'));
|
|
|
267 |
$config->setReturnValue('getValue', 'admin', array('db_user'));
|
|
|
268 |
$config->setReturnValue('getValue', 'secret', array('db_password'));</strong>
|
|
|
269 |
</pre>
|
|
|
270 |
The extra parameter is a list of arguments to attempt
|
|
|
271 |
to match.
|
|
|
272 |
In this case we are trying to match only one argument which
|
|
|
273 |
is the look up key.
|
|
|
274 |
Now when the mock object has the
|
|
|
275 |
<span class="new_code">getValue()</span> method invoked
|
|
|
276 |
like this...
|
|
|
277 |
<pre>
|
|
|
278 |
$config->getValue('db_user')
|
|
|
279 |
</pre>
|
|
|
280 |
...it will return "admin".
|
|
|
281 |
It finds this by attempting to match the calling arguments
|
|
|
282 |
to its list of returns one after another until
|
|
|
283 |
a complete match is found.
|
|
|
284 |
</p>
|
|
|
285 |
<p>
|
|
|
286 |
You can set a default argument argument like so...
|
|
|
287 |
<pre>
|
|
|
288 |
<strong>
|
|
|
289 |
$config->setReturnValue('getValue', false, array('*'));</strong>
|
|
|
290 |
</pre>
|
|
|
291 |
This is not the same as setting the return value without
|
|
|
292 |
any argument requirements like this...
|
|
|
293 |
<pre>
|
|
|
294 |
<strong>
|
|
|
295 |
$config->setReturnValue('getValue', false);</strong>
|
|
|
296 |
</pre>
|
|
|
297 |
In the first case it will accept any single argument,
|
|
|
298 |
but exactly one is required.
|
|
|
299 |
In the second case any number of arguments will do and
|
|
|
300 |
it acts as a catchall after all other matches.
|
|
|
301 |
Note that if we add further single parameter options after
|
|
|
302 |
the wildcard in the first case, they will be ignored as the wildcard
|
|
|
303 |
will match first.
|
|
|
304 |
With complex parameter lists the ordering could be important
|
|
|
305 |
or else desired matches could be masked by earlier wildcard
|
|
|
306 |
ones.
|
|
|
307 |
Declare the most specific matches first if you are not sure.
|
|
|
308 |
</p>
|
|
|
309 |
<p>
|
|
|
310 |
There are times when you want a specific object to be
|
|
|
311 |
dished out by the mock rather than a copy.
|
|
|
312 |
The PHP4 copy semantics force us to use a different method
|
|
|
313 |
for this.
|
|
|
314 |
You might be simulating a container for example...
|
|
|
315 |
<pre>
|
|
|
316 |
class Thing {
|
|
|
317 |
}
|
|
|
318 |
|
|
|
319 |
class Vector {
|
|
|
320 |
function Vector() {
|
|
|
321 |
}
|
|
|
322 |
|
|
|
323 |
function get($index) {
|
|
|
324 |
}
|
|
|
325 |
}
|
|
|
326 |
</pre>
|
|
|
327 |
In this case you can set a reference into the mock's
|
|
|
328 |
return list...
|
|
|
329 |
<pre>
|
|
|
330 |
$thing = &new Thing();<strong>
|
|
|
331 |
$vector = &new MockVector();
|
|
|
332 |
$vector->setReturnReference('get', $thing, array(12));</strong>
|
|
|
333 |
</pre>
|
|
|
334 |
With this arrangement you know that every time
|
|
|
335 |
<span class="new_code">$vector->get(12)</span> is
|
|
|
336 |
called it will return the same
|
|
|
337 |
<span class="new_code">$thing</span> each time.
|
|
|
338 |
This is compatible with PHP5 as well.
|
|
|
339 |
</p>
|
|
|
340 |
<p>
|
|
|
341 |
These three factors, timing, parameters and whether to copy,
|
|
|
342 |
can be combined orthogonally.
|
|
|
343 |
For example...
|
|
|
344 |
<pre>
|
|
|
345 |
$complex = &new MockComplexThing();
|
|
|
346 |
$stuff = &new Stuff();<strong>
|
|
|
347 |
$complex->setReturnReferenceAt(3, 'get', $stuff, array('*', 1));</strong>
|
|
|
348 |
</pre>
|
|
|
349 |
This will return the <span class="new_code">$stuff</span> only on the third
|
|
|
350 |
call and only if two parameters were set the second of
|
|
|
351 |
which must be the integer 1.
|
|
|
352 |
That should cover most simple prototyping situations.
|
|
|
353 |
</p>
|
|
|
354 |
<p>
|
|
|
355 |
A final tricky case is one object creating another, known
|
|
|
356 |
as a factory pattern.
|
|
|
357 |
Suppose that on a successful query to our imaginary
|
|
|
358 |
database, a result set is returned as an iterator with
|
|
|
359 |
each call to <span class="new_code">next()</span> giving
|
|
|
360 |
one row until false.
|
|
|
361 |
This sounds like a simulation nightmare, but in fact it can all
|
|
|
362 |
be mocked using the mechanics above.
|
|
|
363 |
</p>
|
|
|
364 |
<p>
|
|
|
365 |
Here's how...
|
|
|
366 |
<pre>
|
|
|
367 |
Mock::generate('DatabaseConnection');
|
|
|
368 |
Mock::generate('ResultIterator');
|
|
|
369 |
|
|
|
370 |
class DatabaseTest extends UnitTestCase {
|
|
|
371 |
|
|
|
372 |
function testUserFinder() {<strong>
|
|
|
373 |
$result = &new MockResultIterator();
|
|
|
374 |
$result->setReturnValue('next', false);
|
|
|
375 |
$result->setReturnValueAt(0, 'next', array(1, 'tom'));
|
|
|
376 |
$result->setReturnValueAt(1, 'next', array(3, 'dick'));
|
|
|
377 |
$result->setReturnValueAt(2, 'next', array(6, 'harry'));
|
|
|
378 |
|
|
|
379 |
$connection = &new MockDatabaseConnection();
|
|
|
380 |
$connection->setReturnValue('query', false);
|
|
|
381 |
$connection->setReturnReference(
|
|
|
382 |
'query',
|
|
|
383 |
$result,
|
|
|
384 |
array('select id, name from users'));</strong>
|
|
|
385 |
|
|
|
386 |
$finder = &new UserFinder($connection);
|
|
|
387 |
$this->assertIdentical(
|
|
|
388 |
$finder->findNames(),
|
|
|
389 |
array('tom', 'dick', 'harry'));
|
|
|
390 |
}
|
|
|
391 |
}
|
|
|
392 |
</pre>
|
|
|
393 |
Now only if our
|
|
|
394 |
<span class="new_code">$connection</span> is called with the correct
|
|
|
395 |
<span class="new_code">query()</span> will the
|
|
|
396 |
<span class="new_code">$result</span> be returned that is
|
|
|
397 |
itself exhausted after the third call to <span class="new_code">next()</span>.
|
|
|
398 |
This should be enough
|
|
|
399 |
information for our <span class="new_code">UserFinder</span> class,
|
|
|
400 |
the class actually
|
|
|
401 |
being tested here, to come up with goods.
|
|
|
402 |
A very precise test and not a real database in sight.
|
|
|
403 |
</p>
|
|
|
404 |
|
|
|
405 |
<p>
|
|
|
406 |
<a class="target" name="expectations">
|
|
|
407 |
<h2>Mocks as critics</h2>
|
|
|
408 |
</a>
|
|
|
409 |
</p>
|
|
|
410 |
<p>
|
|
|
411 |
Although the server stubs approach insulates your tests from
|
|
|
412 |
real world disruption, it is only half the benefit.
|
|
|
413 |
You can have the class under test receiving the required
|
|
|
414 |
messages, but is your new class sending correct ones?
|
|
|
415 |
Testing this can get messy without a mock objects library.
|
|
|
416 |
</p>
|
|
|
417 |
<p>
|
|
|
418 |
By way of example, suppose we have a
|
|
|
419 |
<span class="new_code">SessionPool</span> class that we
|
|
|
420 |
want to add logging to.
|
|
|
421 |
Rather than grow the original class into something more
|
|
|
422 |
complicated, we want to add this behaviour with a decorator (GOF).
|
|
|
423 |
The <span class="new_code">SessionPool</span> code currently looks
|
|
|
424 |
like this...
|
|
|
425 |
<pre>
|
|
|
426 |
<strong>class SessionPool {
|
|
|
427 |
function SessionPool() {
|
|
|
428 |
...
|
|
|
429 |
}
|
|
|
430 |
|
|
|
431 |
function &findSession($cookie) {
|
|
|
432 |
...
|
|
|
433 |
}
|
|
|
434 |
...
|
|
|
435 |
}
|
|
|
436 |
|
|
|
437 |
class Session {
|
|
|
438 |
...
|
|
|
439 |
}</strong>
|
|
|
440 |
</php>
|
|
|
441 |
While our logging code looks like this...
|
|
|
442 |
<php><strong>
|
|
|
443 |
class Log {
|
|
|
444 |
function Log() {
|
|
|
445 |
...
|
|
|
446 |
}
|
|
|
447 |
|
|
|
448 |
function message() {
|
|
|
449 |
...
|
|
|
450 |
}
|
|
|
451 |
}
|
|
|
452 |
|
|
|
453 |
class LoggingSessionPool {
|
|
|
454 |
function LoggingSessionPool(&$session_pool, &$log) {
|
|
|
455 |
...
|
|
|
456 |
}
|
|
|
457 |
|
|
|
458 |
function &findSession(\$cookie) {
|
|
|
459 |
...
|
|
|
460 |
}
|
|
|
461 |
...
|
|
|
462 |
}</strong>
|
|
|
463 |
</pre>
|
|
|
464 |
Out of all of this, the only class we want to test here
|
|
|
465 |
is the <span class="new_code">LoggingSessionPool</span>.
|
|
|
466 |
In particular we would like to check that the
|
|
|
467 |
<span class="new_code">findSession()</span> method is
|
|
|
468 |
called with the correct session ID in the cookie and that
|
|
|
469 |
it sent the message "Starting session $cookie"
|
|
|
470 |
to the logger.
|
|
|
471 |
</p>
|
|
|
472 |
<p>
|
|
|
473 |
Despite the fact that we are testing only a few lines of
|
|
|
474 |
production code, here is what we would have to do in a
|
|
|
475 |
conventional test case:
|
|
|
476 |
<ol>
|
|
|
477 |
<li>Create a log object.</li>
|
|
|
478 |
<li>Set a directory to place the log file.</li>
|
|
|
479 |
<li>Set the directory permissions so we can write the log.</li>
|
|
|
480 |
<li>Create a <span class="new_code">SessionPool</span> object.</li>
|
|
|
481 |
<li>Hand start a session, which probably does lot's of things.</li>
|
|
|
482 |
<li>Invoke <span class="new_code">findSession()</span>.</li>
|
|
|
483 |
<li>Read the new Session ID (hope there is an accessor!).</li>
|
|
|
484 |
<li>Raise a test assertion to confirm that the ID matches the cookie.</li>
|
|
|
485 |
<li>Read the last line of the log file.</li>
|
|
|
486 |
<li>Pattern match out the extra logging timestamps, etc.</li>
|
|
|
487 |
<li>Assert that the session message is contained in the text.</li>
|
|
|
488 |
</ol>
|
|
|
489 |
It is hardly surprising that developers hate writing tests
|
|
|
490 |
when they are this much drudgery.
|
|
|
491 |
To make things worse, every time the logging format changes or
|
|
|
492 |
the method of creating new sessions changes, we have to rewrite
|
|
|
493 |
parts of this test even though this test does not officially
|
|
|
494 |
test those parts of the system.
|
|
|
495 |
We are creating headaches for the writers of these other classes.
|
|
|
496 |
</p>
|
|
|
497 |
<p>
|
|
|
498 |
Instead, here is the complete test method using mock object magic...
|
|
|
499 |
<pre>
|
|
|
500 |
Mock::generate('Session');
|
|
|
501 |
Mock::generate('SessionPool');
|
|
|
502 |
Mock::generate('Log');
|
|
|
503 |
|
|
|
504 |
class LoggingSessionPoolTest extends UnitTestCase {
|
|
|
505 |
...
|
|
|
506 |
function testFindSessionLogging() {<strong>
|
|
|
507 |
$session = &new MockSession();
|
|
|
508 |
$pool = &new MockSessionPool();
|
|
|
509 |
$pool->setReturnReference('findSession', $session);
|
|
|
510 |
$pool->expectOnce('findSession', array('abc'));
|
|
|
511 |
|
|
|
512 |
$log = &new MockLog();
|
|
|
513 |
$log->expectOnce('message', array('Starting session abc'));
|
|
|
514 |
|
|
|
515 |
$logging_pool = &new LoggingSessionPool($pool, $log);
|
|
|
516 |
$this->assertReference($logging_pool->findSession('abc'), $session);</strong>
|
|
|
517 |
}
|
|
|
518 |
}
|
|
|
519 |
</pre>
|
|
|
520 |
We start by creating a dummy session.
|
|
|
521 |
We don't have to be too fussy about this as the check
|
|
|
522 |
for which session we want is done elsewhere.
|
|
|
523 |
We only need to check that it was the same one that came
|
|
|
524 |
from the session pool.
|
|
|
525 |
</p>
|
|
|
526 |
<p>
|
|
|
527 |
<span class="new_code">findSession()</span> is a factory
|
|
|
528 |
method the simulation of which is described <a href="#stub">above</a>.
|
|
|
529 |
The point of departure comes with the first
|
|
|
530 |
<span class="new_code">expectOnce()</span> call.
|
|
|
531 |
This line states that whenever
|
|
|
532 |
<span class="new_code">findSession()</span> is invoked on the
|
|
|
533 |
mock, it will test the incoming arguments.
|
|
|
534 |
If it receives the single argument of a string "abc"
|
|
|
535 |
then a test pass is sent to the unit tester, otherwise a fail is
|
|
|
536 |
generated.
|
|
|
537 |
This was the part where we checked that the right session was asked for.
|
|
|
538 |
The argument list follows the same format as the one for setting
|
|
|
539 |
return values.
|
|
|
540 |
You can have wildcards and sequences and the order of
|
|
|
541 |
evaluation is the same.
|
|
|
542 |
</p>
|
|
|
543 |
<p>
|
|
|
544 |
We use the same pattern to set up the mock logger.
|
|
|
545 |
We tell it that it should have
|
|
|
546 |
<span class="new_code">message()</span> invoked
|
|
|
547 |
once only with the argument "Starting session abc".
|
|
|
548 |
By testing the calling arguments, rather than the logger output,
|
|
|
549 |
we insulate the test from any display changes in the logger.
|
|
|
550 |
</p>
|
|
|
551 |
<p>
|
|
|
552 |
We start to run our tests when we create the new
|
|
|
553 |
<span class="new_code">LoggingSessionPool</span> and feed
|
|
|
554 |
it our preset mock objects.
|
|
|
555 |
Everything is now under our control.
|
|
|
556 |
</p>
|
|
|
557 |
<p>
|
|
|
558 |
This is still quite a bit of test code, but the code is very
|
|
|
559 |
strict.
|
|
|
560 |
If it still seems rather daunting there is a lot less of it
|
|
|
561 |
than if we tried this without mocks and this particular test,
|
|
|
562 |
interactions rather than output, is always more work to set
|
|
|
563 |
up.
|
|
|
564 |
More often you will be testing more complex situations without
|
|
|
565 |
needing this level or precision.
|
|
|
566 |
Also some of this can be refactored into a test case
|
|
|
567 |
<span class="new_code">setUp()</span> method.
|
|
|
568 |
</p>
|
|
|
569 |
<p>
|
|
|
570 |
Here is the full list of expectations you can set on a mock object
|
|
|
571 |
in <a href="http://www.lastcraft.com/simple_test.php">SimpleTest</a>...
|
|
|
572 |
<table>
|
|
|
573 |
<thead>
|
|
|
574 |
<tr>
|
|
|
575 |
<th>Expectation</th><th>Needs <span class="new_code">tally()</span></th>
|
|
|
576 |
</tr>
|
|
|
577 |
</thead>
|
|
|
578 |
<tbody>
|
|
|
579 |
<tr>
|
|
|
580 |
<td><span class="new_code">expect($method, $args)</span></td>
|
|
|
581 |
<td style="text-align: center">No</td>
|
|
|
582 |
</tr>
|
|
|
583 |
<tr>
|
|
|
584 |
<td><span class="new_code">expectAt($timing, $method, $args)</span></td>
|
|
|
585 |
<td style="text-align: center">No</td>
|
|
|
586 |
</tr>
|
|
|
587 |
<tr>
|
|
|
588 |
<td><span class="new_code">expectCallCount($method, $count)</span></td>
|
|
|
589 |
<td style="text-align: center">Yes</td>
|
|
|
590 |
</tr>
|
|
|
591 |
<tr>
|
|
|
592 |
<td><span class="new_code">expectMaximumCallCount($method, $count)</span></td>
|
|
|
593 |
<td style="text-align: center">No</td>
|
|
|
594 |
</tr>
|
|
|
595 |
<tr>
|
|
|
596 |
<td><span class="new_code">expectMinimumCallCount($method, $count)</span></td>
|
|
|
597 |
<td style="text-align: center">Yes</td>
|
|
|
598 |
</tr>
|
|
|
599 |
<tr>
|
|
|
600 |
<td><span class="new_code">expectNever($method)</span></td>
|
|
|
601 |
<td style="text-align: center">No</td>
|
|
|
602 |
</tr>
|
|
|
603 |
<tr>
|
|
|
604 |
<td><span class="new_code">expectOnce($method, $args)</span></td>
|
|
|
605 |
<td style="text-align: center">Yes</td>
|
|
|
606 |
</tr>
|
|
|
607 |
<tr>
|
|
|
608 |
<td><span class="new_code">expectAtLeastOnce($method, $args)</span></td>
|
|
|
609 |
<td style="text-align: center">Yes</td>
|
|
|
610 |
</tr>
|
|
|
611 |
</tbody>
|
|
|
612 |
</table>
|
|
|
613 |
Where the parameters are...
|
|
|
614 |
<dl>
|
|
|
615 |
<dt class="new_code">$method</dt>
|
|
|
616 |
<dd>The method name, as a string, to apply the condition to.</dd>
|
|
|
617 |
<dt class="new_code">$args</dt>
|
|
|
618 |
<dd>
|
|
|
619 |
The arguments as a list. Wildcards can be included in the same
|
|
|
620 |
manner as for <span class="new_code">setReturn()</span>.
|
|
|
621 |
This argument is optional for <span class="new_code">expectOnce()</span>
|
|
|
622 |
and <span class="new_code">expectAtLeastOnce()</span>.
|
|
|
623 |
</dd>
|
|
|
624 |
<dt class="new_code">$timing</dt>
|
|
|
625 |
<dd>
|
|
|
626 |
The only point in time to test the condition.
|
|
|
627 |
The first call starts at zero.
|
|
|
628 |
</dd>
|
|
|
629 |
<dt class="new_code">$count</dt>
|
|
|
630 |
<dd>The number of calls expected.</dd>
|
|
|
631 |
</dl>
|
|
|
632 |
The method <span class="new_code">expectMaximumCallCount()</span>
|
|
|
633 |
is slightly different in that it will only ever generate a failure.
|
|
|
634 |
It is silent if the limit is never reached.
|
|
|
635 |
</p>
|
|
|
636 |
<p>
|
|
|
637 |
Like the assertions within test cases, all of the expectations
|
|
|
638 |
can take a message override as an extra parameter.
|
|
|
639 |
Also the original failure message can be embedded in the output
|
|
|
640 |
as "%s".
|
|
|
641 |
</p>
|
|
|
642 |
|
|
|
643 |
<p>
|
|
|
644 |
<a class="target" name="approaches">
|
|
|
645 |
<h2>Other approaches</h2>
|
|
|
646 |
</a>
|
|
|
647 |
</p>
|
|
|
648 |
<p>
|
|
|
649 |
There are three approaches to creating mocks including the one
|
|
|
650 |
that SimpleTest employs.
|
|
|
651 |
Coding them by hand using a base class, generating them to
|
|
|
652 |
a file and dynamically generating them on the fly.
|
|
|
653 |
</p>
|
|
|
654 |
<p>
|
|
|
655 |
Mock objects generated with <a href="simple_test.html">SimpleTest</a>
|
|
|
656 |
are dynamic.
|
|
|
657 |
They are created at run time in memory, using
|
|
|
658 |
<span class="new_code">eval()</span>, rather than written
|
|
|
659 |
out to a file.
|
|
|
660 |
This makes the mocks easy to create, a one liner,
|
|
|
661 |
especially compared with hand
|
|
|
662 |
crafting them in a parallel class hierarchy.
|
|
|
663 |
The problem is that the behaviour is usually set up in the tests
|
|
|
664 |
themselves.
|
|
|
665 |
If the original objects change the mock versions
|
|
|
666 |
that the tests rely on can get out of sync.
|
|
|
667 |
This can happen with the parallel hierarchy approach as well,
|
|
|
668 |
but is far more quickly detected.
|
|
|
669 |
</p>
|
|
|
670 |
<p>
|
|
|
671 |
The solution, of course, is to add some real integration
|
|
|
672 |
tests.
|
|
|
673 |
You don't need very many and the convenience gained
|
|
|
674 |
from the mocks more than outweighs the small amount of
|
|
|
675 |
extra testing.
|
|
|
676 |
You cannot trust code that was only tested with mocks.
|
|
|
677 |
</p>
|
|
|
678 |
<p>
|
|
|
679 |
If you are still determined to build static libraries of mocks
|
|
|
680 |
because you want to simulate very specific behaviour, you can
|
|
|
681 |
achieve the same effect using the SimpleTest class generator.
|
|
|
682 |
In your library file, say <em>mocks/connection.php</em> for a
|
|
|
683 |
database connection, create a mock and inherit to override
|
|
|
684 |
special methods or add presets...
|
|
|
685 |
<pre>
|
|
|
686 |
<?php
|
|
|
687 |
require_once('simpletest/mock_objects.php');
|
|
|
688 |
require_once('../classes/connection.php');
|
|
|
689 |
<strong>
|
|
|
690 |
Mock::generate('Connection', 'BasicMockConnection');
|
|
|
691 |
class MockConnection extends BasicMockConnection {
|
|
|
692 |
function MockConnection() {
|
|
|
693 |
$this->BasicMockConnection();
|
|
|
694 |
$this->setReturn('query', false);
|
|
|
695 |
}
|
|
|
696 |
}</strong>
|
|
|
697 |
?>
|
|
|
698 |
</pre>
|
|
|
699 |
The generate call tells the class generator to create
|
|
|
700 |
a class called <span class="new_code">BasicMockConnection</span>
|
|
|
701 |
rather than the usual <span class="new_code">MockConnection</span>.
|
|
|
702 |
We then inherit from this to get our version of
|
|
|
703 |
<span class="new_code">MockConnection</span>.
|
|
|
704 |
By intercepting in this way we can add behaviour, here setting
|
|
|
705 |
the default value of <span class="new_code">query()</span> to be false.
|
|
|
706 |
By using the default name we make sure that the mock class
|
|
|
707 |
generator will not recreate a different one when invoked elsewhere in the
|
|
|
708 |
tests.
|
|
|
709 |
It never creates a class if it already exists.
|
|
|
710 |
As long as the above file is included first then all tests
|
|
|
711 |
that generated <span class="new_code">MockConnection</span> should
|
|
|
712 |
now be using our one instead.
|
|
|
713 |
If we don't get the order right and the mock library
|
|
|
714 |
creates one first then the class creation will simply fail.
|
|
|
715 |
</p>
|
|
|
716 |
<p>
|
|
|
717 |
Use this trick if you find you have a lot of common mock behaviour
|
|
|
718 |
or you are getting frequent integration problems at later
|
|
|
719 |
stages of testing.
|
|
|
720 |
</p>
|
|
|
721 |
|
|
|
722 |
</div>
|
|
|
723 |
<div class="copyright">
|
|
|
724 |
Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004
|
|
|
725 |
</div>
|
|
|
726 |
</body>
|
|
|
727 |
</html>
|