PHP Objects, Patterns, and Practice- P9

PHP Objects, Patterns, and Practice- P9: This book takes you beyond the PHP basics to the enterprise development practices used by professional programmers. Updated for PHP 5.3 with new sections on closures, namespaces, and continuous integration, this edition will teach you about object features such as abstract classes, reflection, interfaces, and error handling. You’ll also discover object tools to help you learn more about your classes, objects, and methods.
Nội dung trích xuất từ tài liệu:
PHP Objects, Patterns, and Practice- P9C H A P T E R 18■■■Testing with PHPUnitEvery component in a system depends, for its continued smooth running, on the consistency ofoperation and interface of its peers. By definition, then, development breaks systems. As you improveyour classes and packages, you must remember to amend any code that works with them. For somechanges, this can create a ripple effect, affecting components far away from the code you originallychanged. Eagle-eyed vigilance and an encyclopedic knowledge of a system’s dependencies can help toaddress this problem. Of course, while these are excellent virtues, systems soon grow too complex forevery unwanted effect to be easily predicted, not least because systems often combine the work of manydevelopers. To address this problem, it is a good idea to test every component regularly. This, of course,is a repetitive and complex task and as such it lends itself well to automation. Among the test solutions available to PHP programmers, PHPUnit is perhaps the most ubiquitousand certainly the most fully featured tool. In this chapter, you will learn the following about PHPUnit: • Installation: Using PEAR to install PHPUnit • Writing Tests: Creating test cases and using assertion methods • Handling Exceptions: Strategies for confirming failure • Running multiple tests: Collecting tests into suites • Constructing assertion logic: Using constraints • Faking components: Mocks and stubs • Testing web applications: With and without additional tools.Functional Tests and Unit TestsTesting is essential in any project. Even if you don’t formalize the process, you must have found yourselfdeveloping informal lists of actions that put your system through its paces. This process soon becomeswearisome, and that can lead to a fingers-crossed attitude to your projects. One approach to testing starts at the interface of a project, modeling the various ways in which auser might negotiate the system. This is probably the way you would go when testing by hand, althoughthere are various frameworks for automating the process. These functional tests are sometimes calledacceptance tests, because a list of actions performed successfully can be used as criteria for signing off aproject phase. Using this approach, you typically treat the system as a black box—your tests remainingwillfully ignorant of the hidden components that collaborate to form the system under test. Whereas functional tests operate from without, unit tests (the subject of this chapter) work from theinside out. Unit testing tends to focus on classes, with test methods grouped together in test cases. Eachtest case puts one class through a rigorous workout, checking that each method performs as advertised 379 CHAPTER 18 ■ TESTING WITH PHPUNIT and fails as it should. The objective, as far as possible, is to test each component in isolation from its wider context. This often supplies you with a sobering verdict on the success of your mission to decouple the parts of your system. Tests can be run as part of the build process, directly from the command line, or even via a web page. In this chapter, I’ll concentrate on the command line. Unit testing is a good way of ensuring the quality of design in a system. Tests reveal the responsibilities of classes and functions. Some programmers even advocate a test-first approach. You should, they say, write the tests before you even begin work on a class. This lays down a class’s purpose, ensuring a clean interface and short, focused methods. Personally, I have never aspired to this level of purity—it just doesn’t suit my style of coding. Nevertheless, I attempt to write tests as I go. Maintaining a test harness provides me with the security I need to refactor my code. I can pull down and replace entire packages with the knowledge that I have a good chance of catching unexpected errors elsewhere in the system. Testing by Hand In the last section, I said that testing was essential in every project. I could have said instead that testing is inevitable in every project. We all test. The tragedy is that we often throw away this good work. So, let’s create some classes to test. Here is a class that stores and retrieves user information. For the sake of demonstration, it generates arrays, rather than the User objects youd normally expect to use: class UserStore { private $users = array(); function addUser( $name, $mail, $pass ) { if ( isset( $this->users[$mail] ) ) { throw new Exception( User {$mail} alrea ...