Test Driven Development with PHP

Presented at the May 2012 Singapore PHP User Group Meetup.

Transcript

1. The secret to coding with confidence Test Driven Development Tuesday, May 22, 12
2. Tuesday, May 22, 12
3. Tuesday, May 22, 12
4. Tuesday, May 22, 12
5. What is TDD? • Getting into the habit of writing tests before writing code. • TDD are continuous short cycle of test, code, refactor. • Test cases are in separate files. No more print_r & var_dump in your code! • The tests contain assertions that are either true or false. Passing the tests confirms correct behavior of the code. Tuesday, May 22, 12
6. What is TDD? • Old way: • Write code first, test if you have time. • Often times, you'll be too exhausted (mentally) at the end of coding process to write tests. Tuesday, May 22, 12
7. What is TDD? Tuesday, May 22, 12
8. What is TDD? Tuesday, May 22, 12
9. What is TDD? Tuesday, May 22, 12
10. What is TDD? Tuesday, May 22, 12
11. Tuesday, May 22, 12
12. Why TDD? • TDD gives you higher confidence that your code is doing what it's suppose to. • Small wins makes the coding process more enjoyable (Gamification). • Working code every step of the way! Tuesday, May 22, 12
13. TDD Process 1 Feature specifications 2 Write test cases 3 Tests will fail 4 Write code to pass the tests (minimal) 5 Pass all tests 6 Refactor "Make it green, then make it clean" Tuesday, May 22, 12
14. TDD Process • By focusing on writing only the code necessary to pass tests, designs can be cleaner and clearer than is often achieved by other methods. • Resist the urge to pre-optimize the code. Just make it pass first. • Too many asserts might be a sign that your function is doing too many things - break it into smaller chunks. • No code is perfect. Tuesday, May 22, 12
15. Benefits • Better Code Design • Modular - If it breaks, it's isolated and easily traceable. • Testable units speed up development - Update the test case, make the code change, run the tests. • Confidence in making larger change sets. Tuesday, May 22, 12
16. Benefits • Detect if other parts of your app is affected by the latest code change. • Coverage reports help you discover potential weak spots / blind spots in your code. • Tests with examples will help in simulating actual use cases in an automated manner. • Tests becomes the documentation. Tuesday, May 22, 12
17. Adoption Strategies • Legacy Codebase • Identify critical path, generate skeleton test cases & write test cases. • Write tests for new features &/or code that are accessed by the new feature. Tuesday, May 22, 12
18. Adoption Strategies • New Projects • Establish a workflow and make the automated test part of your release process. Tuesday, May 22, 12
19. Adoption Strategies • Developers who write their own tests might have a tendency to take shortcuts by writing conservative test cases. • One way to prevent this is to pair-program with another developer or a product owner when preparing the test cases. • Spec documents that includes examples can be useful to validate code behavior. Tuesday, May 22, 12
20. • PHPUnit is the de-facto standard for unit testing in PHP projects. It provides both a framework that makes the writing of tests easy as well as the functionality to easily run the tests and analyse their results. • http://phpunit.de • Created by Sebastian Bergmann Tuesday, May 22, 12
21. Demo Tuesday, May 22, 12
22. Demo Script • Installing PHPUnit. • Use existing class to generate tests. • Use test cases to generate class file. • Coverage Report. • Behavior Driven Development. Tuesday, May 22, 12
23. Installing PHPUnit # pear config-set auto_discover 1 # pear install pear.phpunit.de/PHPUnit Tuesday, May 22, 12
24. Sample Code https://github.com/miccheng/TDD-PHP-Sample Tuesday, May 22, 12
25. Behavior Driven Development (BDD) • Not just testing individual units, but testing the codes as a user would use your app (ie. how diff parts of your code work together). • Process is the same, just that the tests are story-based. • User stories = Specs with examples Tuesday, May 22, 12
26. Caveat • It's gonna take some time to get productive • Read: Downtime of at least 1-2 days • Nothing is full-proof! • It's easy to get lured into a false sense of security. • Even if u have 100% coverage, it still doesn't prevent unintended usage from breaking the code. • Bugs are test cases you have not written yet. Tuesday, May 22, 12
27. End of File Tuesday, May 22, 12