Effective Testing for PHP Applications

When it comes to testing, there's a long list of different types (there's unit, functional, integration, performance, usability and acceptance testing to name a few!). In this talk, David Chang from Chefs Plate will cover several of the common types of testing, what the popular PHP testing tools are, and what they can be used for. This talk will also discuss practical starting points for unit testing and testing coverage, how to ensure you focus your testing on the right components, making tests scalable and quick, and will briefly touch on how continuous integration fits into the larger picture.

Transcript

1. 2017.11.01 #LaravelTO
2. Chefs Plate • We're hiring! ◦ Front-End Developer (x2) ◦ Data Engineer ◦ Product Owner - Mobile ◦ IT Manager ◦ IT Administrator ◦ Plus many more! Check out https://www.chefsplate.com/careers
3. EFFECTIVE TESTING FOR PHP APPLICATIONS Presented by David Chang Twitter: @davidchchang
4. “ Software and cathedrals are much the same: first we build them, then we pray. - Anonymous
5. Not exactly the best way to test code
6. “ Weeks of programming can save you hours of planning (and writing tests). - Anonymous
7. Source: Software Engineering StackExchange (https://softwareengineering.stackexchange.com/a/91764/232196)
8. =
9. =
10. ON THE MENU Agenda: ◦ Why is Testing Important? ✔ ◦ Types of Testing ◦ PHP Testing Tools ◦ Testing guidelines ◦ Integrating with CI ◦ CI Action Plan
11. TYPES OF TESTING What are they are why are they useful? 1
12. IT'S EASY TO GET LOST Unit Testing Integration Testing Systems Testing Acceptance Testing Functional Testing Usability Testing Stress/Load Testing Security Testing Smoke Testing Regression Testing Accessibility Testing Automated Testing White-box Testing Black-box Testing API Testing Static Testing Dynamic Testing Code Coverage Non-Functional Testing Model-Based Testing Exploratory Testing Ad Hoc Testing Visual Testing Grey-box Testing GUI Testing Sanity Testing
13. MAIN LEVELS OF TESTING UNIT TESTING INTEGRATION TESTING SYSTEMS TESTING (USER) ACCEPTANCE TESTING
14. ◦ Tests the smallest testable part of the code, usually individual functions ◦ Usually tested in isolation, with the help of method stubs, mocks and test harnesses ◦ Objective: isolate a unit of code and validate its correctness. UNIT TESTING
15. EXAMPLE OF A UNIT TEST
16. EXAMPLE OF A UNIT TEST
17. UNIT TESTING: PROS AND CONS Cons: ◦ Setting up realistic or practical test cases not always easy ◦ Like documentation, difficult to constantly maintain for accuracy Pros: ◦ Early detection of problems ◦ Allows developers to think through various conditions, providing more structure and improving code design ◦ Great help during refactors
18. ◦ Larger tests are grouped into modules and those are tested as a group ◦ Objective: reveal issues between integrated components of a system ◦ Can help identify gaps that were not caught in unit testing ◦ Commonly referred to as functional or framework tests INTEGRATION TESTING
19. EXAMPLE OF AN INTEGRATION TEST
20. ◦ Was the postal code validated when it was submitted? ◦ Did we return the appropriate error if it was invalid? EXAMPLE OF AN INTEGRATION TEST
21. NO INTEGRATION TESTS
22. ◦ End-to-end testing of a particular feature ◦ Objective: ensure your feature/application is ready for production SYSTEMS TESTING
23. Examples: ◦ When submitting the customer email, was the email persisted correctly in the database or the email service provider? ◦ Was the customer added to the correct mailing list? ◦ Did we protect against spammers? Did we introduce any vulnerabilities or performance issues? SYSTEMS TESTING
24. ◦ Performed by product owner/client ◦ Objective: confirm that requirements for project were met ◦ Example: ▫ Marketing team to confirm the email was correctly added to the right mailing list ▫ They might also confirm that the email has the correct fields embedded (USER) ACCEPTANCE TESTING
25. MAIN LEVELS OF TESTING UNIT TESTING INTEGRATION TESTING SYSTEMS TESTING (USER) ACCEPTANCE TESTING
26. PHP TESTING TOOLS What are the most common tools and when should they be used? 2
27. TDD vs BDD ◦ TDD: Test-Driven Development ◦ BDD: Behaviour-Driven Development ◦ Both write unit tests before coding. Main difference: ◦ TDD (e.g. PhpUnit) uses PHP code for tests ◦ BDD (e.g. Behat) uses human-readable sentences
28. EXAMPLE OF A UNIT TEST IN PHPUNIT
29. What's wrong with PhpUnit? Nothing really. It can be used to test anything. However, because it is so generalized, more specialized tools can help to enforce good coding practices. WHAT ABOUT PHPUNIT?
30. ◦ Multi-purpose: can handle unit, functional, API & acceptance tests ◦ Superset of PhpUnit ◦ Write test code in PHP
31. Codeception as a superset of PhpUnit
32. BDD acceptance testing with Codeception
33. ◦ BDD tool that allows business people to write software rules without being a developer ◦ Behat is the PHP implementation of Ruby's Cucumber ◦ Uses Gherkin syntax instead of PHP; can take longer to onboard for PHP developers
34. BEHAT & STORYBDD
35. BEHAT & STORYBDD
36. GTA PHP hosting a meetup about testing Behat with Docker
37. “ PhpSpec, which I maintain, is a tool for designing classes that work well. It's best used to drive the design of a clean, decoupled, isolated domain model without getting too involved in infrastructure. - Ciaran McNulty
38. More like SpecBDD compared to Behat's StoryBDD
39. PHPSPEC & SPECBDD
40. PHPSPEC & SPECBDD
41. PHPSPEC & SPECBDD
42. ◦ Great tool for testing web application UIs ◦ Not just limited to PHP
43. Use whichever tool works for you. THE FINAL VERDICT
44. TESTING GUIDELINES How do we know we're testing the right things? 3
45. UNIT TEST COVERAGE Shouldn't we just focus on getting unit test coverage to 100%? 3*
46. 3 TYPES OF CODE COVERAGE Once you have Xdebug installed, you can use PhpUnit to determine code coverage: ◦ Line coverage ◦ Function/method coverage ◦ Class/trait coverage ◦ Branch coverage ◦ Path coverage ◦ Change Risk Anti-Patterns (CRAP) Index
47. 3 UNIT TEST COVERAGE REPORT
48. 100% code coverage is a little bit misleading though...
49. “ No amount of testing can prove a software right, a single test can prove a software wrong. - Amir Ghahrai, testingexcellence.com
50. SOME BAD THINGS TO TEST ◦ Testing a built-in library function (E.g. Math.round or array_unshift) ◦ Testing that when a button is clicked, that the button was clicked ◦ Individual getters and setters
51. WHAT NEEDS TO BE TESTED? Some ideas: ◦ Start with the risky and complex elements first ◦ Test components that are commonly used ◦ Testing assumptions about evolving APIs
52. Source: Steve Sanderson, Selective Unit Testing – Costs and Benefits
53. ◦ Middleware & router ◦ Authorization/authentication ◦ Error handling (how our API handles thrown exceptions) ◦ Payment & email, etc. ◦ Data layer & graceful degradation ◦ Localizations ◦ Expected response formats WHAT ARE HIGH IMPACT AREAS?
54. HOW TO MAKE TESTS SCALABLE? When you have many tests or they are taking a long time: ◦ De-couple from database ◦ Mock expensive or difficult to reproduce calls (esp. third party) ◦ Run tests in parallel
55. UNIT TESTING FUNCTION CALLS WITH MOCKERY
56. PARALLEL UNIT TESTING WITH PARATEST
57. Paratest helps speed up performance significantly. Source: @zizacozizaco PARALLEL UNIT TESTING WITH PARATEST
58. But be careful: ◦ Certain tests with dependencies (e.g. CRUD tests, queuing jobs) may be harder to run in parallel PARALLEL UNIT TESTING WITH PARATEST
59. INTEGRATING TESTS WITHIN CI How testing fits into the bigger picture 4
60. CI has one primary purpose: To improve the quality and speed of software delivery. PURPOSE OF CONTINUOUS INTEGRATION
61. Jenkins in Action Source: National Instruments, Getting Started with TestStand and Jenkins
62. ◦ Don't run unit tests during CI ▫ Should be tested during development ◦ Focus on integration and systems tests (e.g. security, performance), and core suite of critical components PRIORITIES FOR CI TESTS
63. CONTINUOUS INTEGRATION IN 8 (EASY) STEPS 1. Convert integration tests into unit tests (or create unit tests) ▫ We need to make it clear where functionality is failing, which is not that clear with integration tests ▫ Remove DB dependencies 2. Automatically run unit tests upon commit ▫ Forbid pushes that do not pass tests 3. Fix all failing unit tests
64. CONTINUOUS INTEGRATION IN 8 (EASY) STEPS 4. Identify areas for parallelization (say that three times fast) ▫ E.g. jobs need to be tested immediately ▫ Certain CRUD operations need to be tested in sequence 5. Create integration test suite ▫ Define test data set needed ▫ Should comprise of critical (high priority) unit tests as well ▫ Staging/production security checks (e.g. uptime robot)
65. CONTINUOUS INTEGRATION IN 8 (EASY) STEPS 6. Run integration tests during build process (within CI framework) ▫ Whoever breaks the build should be notified and assigned immediately. ▫ Policy should be: Can't go home unless issue is resolved; can roll back. ▫ Blow it up in Slack if needed. 7. Work with DevOps teams to build out systems tests ▫ 7b) Hire DevOps team 8. Communicate plan and create development tickets
66. SonarQube for PHP
67. Thanks! ANY QUESTIONS?
68. CREDITS Special thanks to SlidesCarnival for releasing this presentation template for free See you next month at: Chefs Plate Wednesday, December 13, 2017 Talk: Performance Tuning your PHP Applications Presented by David Chang (@davidchchang)
69. BOOKS TO READ Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Jez Humble, David Farley