| [ Index ] |
|
Code source de PRADO 3.0.6 |
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>
titre
Description
Corps
titre
Description
Corps
titre
Description
Corps
titre
Corps
| Généré le : Sun Feb 25 21:07:04 2007 | par Balluche grâce à PHPXref 0.7 |