Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Effective Testing for PHP Applications

David Chang
November 01, 2017

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.

David Chang

November 01, 2017
Tweet

More Decks by David Chang

Other Decks in Programming

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