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

BeTesting

 BeTesting

A-Z of testing. How to start, how to be better, how to be best

Aa0518da9d7119444cb02a8f27017d8a?s=128

Michael Bodnarchuk

July 26, 2015
Tweet

More Decks by Michael Bodnarchuk

Other Decks in Programming

Transcript

  1. PHPKonf Istanbul 2015 Michael Bodnarchuk BEYOND TESTING

  2. PHPKonf Istanbul 2015 Michael Bodnarchuk BE TESTING

  3. WHO AM I • Michael Bodnarchuk @davert • Web-developer from

    Kyiv, Ukraine • Lead developer of Codeception testing framework and other OS tools like: Robo, AspectMock, etc
  4. FEW WORDS ABOUT UKRAINE • Yes! It is really interesting

    to live here • Mass festivals with fire shows • We have cheap beer (and pretty much everything) • We don't pay taxes as we don't trust government. We donate to volunteers
  5. CITIZEN HELPS POLICEMAN TO INSTALL VLC PLAYER

  6. WHAT IS IT ALL ABOUT • Why you should test

    your projects • What is automated testing • What kind of tests exist • What testing tools you can use • How to write a test the best way • Testing is fun!
  7. HOW CAN WE TEST? • Manual • Automated

  8. AUTOMATED TESTING IS TO... • test typical interaction scenarios •

    verify functionality in current period of time • check system from inside and outside
  9. LET’S TEST THIS BOX

  10. Criteria Black Box Testing White Box Testing Definition Black Box

    Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is NOT known to the tester White Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester. Levels Applicable To Mainly applicable to higher levels of testing:Acceptance Testing System Testing Mainly applicable to lower levels of testing:Unit Testing Integration Testing Responsibility Generally, independent Software Testers Generally, Software Developers Programming Knowledge Not Required Required Implementation Knowledge Not Required Required Basis for Test Cases Requirement Specifications Detail Design
  11. KINDS OF TESTS • Acceptance • Functional • Integration •

    Unit
  12. ACCEPTANCE TESTS ARE • about UI testing • perform actions

    from end-users perspective • use browser / webserver / database • practically any web application can be tested this way
  13. FUNCTIONAL TESTS ARE • about testing features • emulate user

    actions via HTTP requests • incorporates framework internals • similar to acceptance tests
  14. INTEGRATION TESTS ARE • about testing autonomous code parts •

    those parts can use database / filesystem / etc
  15. UNIT TESTS ARE • about testing minimal available units (classes)

    • units are tested in isolation • assuring you that each codeline is necessary
  16. WHAT WE NEED FOR TESTING? • Acceptance: Selenium+browser || PhantomJS

    || browser emulator, web- server, database • Functional: framework, database • Integration: database • Unit: following SOLID principles on development, mocking dependencies
  17. TESTS CRITERIA • Execution Stability ↓ • Stability to Changes

    ↑ • Speed ↓ • Coverage ↑ • Preciseness ↓ • Readability ↕ Unit => Integration => Functional => Acceptance
  18. TOOLS FOR TESTING YOU SHOULD PROBABLY KNOW

  19. PHPUNIT • Standard de-facto • Monolithic framework • Two mocking

    engines included (why not 3?) • JUnit, HTML, reports... and codecoverage • And other 100500 sometimes used features
  20. PHPSPEC • TDD framework • Classes are generated from tests

    • Dependencies are described through mocking • Does not replace PHPUnit • For development, not for testing
  21. BEHAT • BDD-framework • Ubiquitous language (Gherkin) • Acceptance testing

    via Mink (Selenium, Goutte, etc)
  22. CODECEPTION • BDD-style testing framework • Scenario DSL for describing

    tests • Over 20 modules to cover the most of possible cases • Testing via Selenium, PhpBrowser, frameworks...
  23. CONTINUOUS INTEGRATION SERVER • Automatically executes tests • Can be

    used to validate Pull Requests • Prevents you from merging bad code into release branch
  24. THERE ARE MANY OF THEM!

  25. WHICH ONE TO CHOOSE? • TravisCI SaaS, simplest but expensive

    (for non OS) • Jenkins self-hosted, free but outdated • PHPCI - for true PHP fanatics • TeamCity - self-hosted, non-free, modern • CodeShip, CirecleCI, … - SaaS like Travis, cheaper
  26. BEST PRACTICES SOME KIND OF

  27. TEST STRUCTURE ▪Condition (Given) ▪Action (When) ▪Assertion (Then)

  28. HOW TO WRITE UNIT / INTEGRATION TEST • Install PHPUnit

    • Pick isolated codepiece (or write a new one) • Check the code provides expected result on call • Separate configuration and support code from test • Do not use hierarchy for testcases (use traits)
  29. LEARN UNIT TESTS FROM OPEN-SOURCE move to configuration use traits

  30. DON'T DO IT THIS WAY move to configuration use traits

  31. IMPLEMENT YOUR OWN ASSERTIONS custom assertions make code more readable

  32. MAKE IT SIMPLER!

  33. HOW TO WRITE FUNCTIONAL/ACCEPTANCE TEST • Install Codeception http://codeception.com •

    Write a scenario reproducing user activity on site • Choose the way it will be executed (PhpBrowser, WebDriver, one of Frameworks)
  34. LEARN FROM CODECEPTION DOCS =)

  35. CODECEPTION BEST PRACTICES • Use Cest testing format (tests in

    classes) • Store repeating locators as PageObjects • Combine stacked actions into one • Use Dependency Injection to insert support classes
  36. HERE HOW YOUR TEST WILL LOOK LIKE

  37. CONCLUSION DIDN’T YOU START TESTING YET?

  38. WHAT WAY SHOULD I TEST MY STUFF? • Start testing

    the way you can. Test it on all possible levels. • Unit tests will need code to be testable • Integration/Functional tests will need database management • Acceptance tests will require environment prepared
  39. QUESTIONS? • My name is Michael Bodnarchuk • Twitter: @davert

    • GitHub: DavertMik • ….and don't forget to try http://codeception.com