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
   

   View Slide

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
   

   View Slide

3. EFFECTIVE
   TESTING FOR
   PHP
   APPLICATIONS
   Presented by David Chang
   Twitter: @davidchchang
   

   View Slide

4. “
   Software and cathedrals are much the
   same: first we build them, then we pray.
   - Anonymous
   

   View Slide

5. Not exactly the best way to test code
   

   View Slide

6. “
   Weeks of programming can save you
   hours of planning (and writing tests).
   - Anonymous
   

   View Slide

7. Source: Software Engineering StackExchange
   (https://softwareengineering.stackexchange.com/a/91764/232196)
   

   View Slide

8. =
   

   View Slide

9. =
   

   View Slide

10. ON THE MENU
    Agenda:
    ◦ Why is Testing Important? ✔
    ◦ Types of Testing
    ◦ PHP Testing Tools
    ◦ Testing guidelines
    ◦ Integrating with CI
    ◦ CI Action Plan
    

    View Slide

11. TYPES OF TESTING
    What are they are why are they useful?
    1
    

    View Slide

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
    

    View Slide

13. MAIN LEVELS OF TESTING
    UNIT TESTING
    INTEGRATION TESTING
    SYSTEMS TESTING
    (USER) ACCEPTANCE
    TESTING
    

    View Slide

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
    

    View Slide

15. EXAMPLE OF A UNIT TEST
    

    View Slide

16. EXAMPLE OF A UNIT TEST
    

    View Slide

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
    

    View Slide

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
    

    View Slide

19. EXAMPLE OF AN INTEGRATION TEST
    

    View Slide

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
    

    View Slide

21. NO INTEGRATION TESTS
    

    View Slide

22. ◦ End-to-end testing of a particular
    feature
    ◦ Objective: ensure your
    feature/application is ready for
    production
    SYSTEMS TESTING
    

    View Slide

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
    

    View Slide

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
    

    View Slide

25. MAIN LEVELS OF TESTING
    UNIT TESTING
    INTEGRATION TESTING
    SYSTEMS TESTING
    (USER) ACCEPTANCE
    TESTING
    

    View Slide

26. PHP TESTING TOOLS
    What are the most common tools and when should they be
    used?
    2
    

    View Slide

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
    

    View Slide

28. EXAMPLE OF A UNIT TEST IN PHPUNIT
    

    View Slide

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?
    

    View Slide

30. ◦ Multi-purpose: can handle unit,
    functional, API & acceptance tests
    ◦ Superset of PhpUnit
    ◦ Write test code in PHP
    

    View Slide

31. Codeception as a superset of PhpUnit
    

    View Slide

32. BDD acceptance testing with Codeception
    

    View Slide

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
    

    View Slide

34. BEHAT & STORYBDD
    

    View Slide

35. BEHAT & STORYBDD
    

    View Slide

36. GTA PHP hosting a meetup about testing Behat with Docker
    

    View Slide

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
    

    View Slide

38. More like SpecBDD compared to
    Behat's StoryBDD
    

    View Slide

39. PHPSPEC & SPECBDD
    

    View Slide

40. PHPSPEC & SPECBDD
    

    View Slide

41. PHPSPEC & SPECBDD
    

    View Slide

42. ◦ Great tool for testing web
    application UIs
    ◦ Not just limited to PHP
    

    View Slide

43. Use whichever tool works for you.
    THE FINAL VERDICT
    

    View Slide

44. TESTING GUIDELINES
    How do we know we're testing the right things?
    3
    

    View Slide

45. UNIT TEST COVERAGE
    Shouldn't we just focus on getting unit test coverage to 100%?
    3*
    

    View Slide

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
    

    View Slide

47. 3
    UNIT TEST COVERAGE REPORT
    

    View Slide

48. 100% code coverage is a little bit misleading though...
    

    View Slide

49. “
    No amount of testing can prove a
    software right, a single test can prove a
    software wrong.
    - Amir Ghahrai, testingexcellence.com
    

    View Slide

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
    

    View Slide

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
    

    View Slide

52. Source: Steve Sanderson, Selective Unit Testing – Costs and Benefits
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

55. UNIT TESTING FUNCTION CALLS WITH MOCKERY
    

    View Slide

56. PARALLEL UNIT TESTING WITH PARATEST
    

    View Slide

57. Paratest helps speed up performance
    significantly.
    Source: @zizacozizaco
    PARALLEL UNIT TESTING WITH PARATEST
    

    View Slide

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
    

    View Slide

59. INTEGRATING TESTS WITHIN CI
    How testing fits into the bigger picture
    4
    

    View Slide

60. CI has one primary purpose:
    To improve the quality and speed of
    software delivery.
    PURPOSE OF CONTINUOUS INTEGRATION
    

    View Slide

61. Jenkins in Action
    Source: National Instruments, Getting Started with TestStand and
    Jenkins
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

66. SonarQube for PHP
    

    View Slide

67. Thanks!
    ANY QUESTIONS?
    

    View Slide

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)
    

    View Slide

69. BOOKS TO READ
    Continuous Delivery:
    Reliable Software
    Releases through Build,
    Test, and Deployment
    Automation
    Jez Humble, David Farley
    

    View Slide