![]() ![]() Previously in my PHPUnit tutorial series, you learned about the very powerful concept of mock objects and stub methods. Unit Testing Tutorial Part V: Mock Methods and Overriding Constructors.Unit Testing Tutorial Part IV: Mock Objects, Stub Methods and Dependency Injection.Unit Testing Tutorial Part II: Assertions, Writing a Useful Test and Unit Testing Tutorial Part III: Testing Protected/Private Methods, Coverage Reports and CRAP.Unit Testing Tutorial Part I: Introduction to PHPUnit. ![]() Below are the links to other parts of this tutorial! Here's how you might use it with a closure (the closure requires PHP 5.This is Part V of a multi-part series. ![]() The callback function is passed a cloned copy of the parameters received by the method in the class under test (note they are not 'live' references so you can't make any persistent changes to them in the callback). Mocking with a Callback FunctionThe returnCallback('callback_function') method will create a mock that returns a value determined at runtime by the specified callback function. The stub's return value is calculated by the named callback function Return the instance of the class under test Return the method argument specified by its position in the argument list When called, the stubbed method will throw the exception specified in the argument ![]() The map is a 2D array of arrays, where the first elements of each subarray are values that must match the arguments for the remaining element to be used as return value The first time the mocked method is called, $val 1 is returned, the second time $val 2 is returned, and so on. The other methods that we could use are: returnValue($val) Note that instead of the number 10, we could have any PHP value, from strings, to arrays, even an object reference. $this ->_object -> expects ( $this -> any ( ) ) -> method ( '_callAPImethod' ) -> will ( $this -> returnValue ( 10 ) ) What the above does is configure the mock object such that the _callAPImethod() will return the value 10, for any parameters. When instantiating the class under test in the setUp() method, use the getMock() method of your test class (inherited from the superclass), with the second argument an array of methods that are to be mocked: Mocking such methods is pretty straightforward. Mocking MethodsWhen testing a class that consumes an external service, the best design approach is to place the code which calls the external API in a single protected method, and then call that method from other methods in your code when they need to use the services of the API. If our collection acted a bit like a stack for example, we'd also want our test code to check that the order of items retrieved from the collection matches our expectations based on the order in which they were added. The tests we choose to create are specific to the code under test. For instance, a collection class should have a size of zero immediately after being created, and as further elements are added the size should change accordingly. When we write unit tests, we are generally testing that a class behaves as expected given certain inputs. They do certainly add to the development timeframe, and have a small overhead when releasing code, but the advantage of avoiding code releases without proper testing when, for instance, code is assumed to be sound because it was tested just prior to an apparently minor change. Even if the tests are run manually, they offer uniformity in testing. The big advantage of automated tests is their repeatability: implemented as part of a deployment process they can highlight code problems without developer interaction. Additionally, the concept of inheritance can be leveraged to allow test code to gain access to the internals of a class even when they are marked protected, and reflection can be used to examine the values of private properties. Unit testing is naturally suited to OOP systems, as classes are very modular components that can be readily instantiated and tested in isolation by the test application. When these automated tests fail, the idea is that they will pinpoint where the problem lies and what causes it. The basic idea behind unit testing is that the different components of an application can be tested individually (as a unit no less) by calling each component from a test application passing in a range of suitably picked parameters. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |