TDD with phpspec2

4,320 views

Published on

Published in: Software
  • Hi Anton, nice slideshow. Although I do not agree with at least one part. In my opinion the domain layer should be free of any libraries and code that does not concern your domain logic, Other concerns like persistance should also be decouple from the domain. On slide 38 you state that Doctrine entities should be used as Domain entities when possible. In case of Doctrine I fullt disagree with this. Doctrine entities and mainly "* to many" relationships need a doctrine collection to hold the related entites. This means that the specific Doctrine collection class will leak all over your domain services and entities which actually only should contain domain logic. Doctrine entities in the domain cause tight coupling of your domain code to Doctrine which means that it will be very hard to change your domain implementation to use a different vendor than Doctrine. Kind regards
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

TDD with phpspec2

  1. 1. TDD with phpspec2
  2. 2. Who I am • Anton Serdyuk • email/jabber: anton.serdyuk@gmail.com • skype: serdyuk.anton • twitter: @anton_serdyuk • facebook: anton.serdyuk
  3. 3. Overview
  4. 4. Auto-tests forms • Functional tests (+BDD) • Integration tests • Unit tests
  5. 5. Functional tests • Use full deployed application instance • Test business expectations • Use the same UI interactions as real user
  6. 6. Functional tests with phpunit example
  7. 7. BDD (or story BDD) • Story-driven functional tests • BDD ⊂ Functional tests
  8. 8. BDD with behat example
  9. 9. Integration tests • Use integrated parts of applications • Can use database, filesystem etc. • Can test API, Doctrine repositories etc.
  10. 10. Integration tests with PHPUnit example
  11. 11. Unit tests • Use small parts of code • Can not use database • Can not use filesystem • Extremely fast
  12. 12. Consider using appropriate tools for tests phpunit behat phpspec codeception Functional + + + Integration + + (sometimes) + Unit + + +
  13. 13. My personal preference • behat for functional and API integration tests • PHPUnit for integration tests • phpspec for unittest
  14. 14. phpspec basics
  15. 15. Installation
  16. 16. Create test for class WowHero
  17. 17. Run tests phpspec will create classes for you
  18. 18. Run tests generated class WowHero
  19. 19. Run tests Run tests again, now with generated class
  20. 20. Matchers (assertions) Every hero has level
  21. 21. Matchers phpspec will generate code for you
  22. 22. Matchers phpspec will generate code for you
  23. 23. Matchers Red
  24. 24. Matchers Green
  25. 25. Matchers Refactor
  26. 26. Matchers • Identity (return, be, equal, beEqualTo) - === • Comparison (beLike) - == • Throw (throw -> during) - exceptions • Type (beAnInstanceOf etc.) - type • Custom matchers • http://www.phpspec.net/cookbook/matchers.html
  27. 27. Matchers Use source code for more matchers
  28. 28. Exception Matchers Generate
  29. 29. Exception Matchers Generate
  30. 30. Exception Matchers Generate
  31. 31. Exception Matchers Red
  32. 32. Exception Matchers Green
  33. 33. Mocks Every Hero has race and class
  34. 34. Mocks Generate
  35. 35. Mocks Generate
  36. 36. Mocks Generate
  37. 37. Mocks Red
  38. 38. Mocks Green
  39. 39. Mocks Green (whoops!)
  40. 40. Mocks Green
  41. 41. Mocks Refactor - let() / letgo()
  42. 42. Mocks Refactor - let() / letgo()
  43. 43. Mocks Refactor
  44. 44. Predictions
  45. 45. Predictions Red
  46. 46. Predictions Green
  47. 47. Predictions Red
  48. 48. Predictions Green
  49. 49. Advanced topics
  50. 50. Nested Object Matchers
  51. 51. Public Property Mock Sometimes you want to mock public properties
  52. 52. Promises and Predictions Order 1) Promises -> 2) Predictions -> 3) Call
  53. 53. Promises and Predictions Order 1) Promises -> 2) Predictions -> 3) Call
  54. 54. Promises and Predictions Order 1) Promises -> 2) Predictions -> 3) Call
  55. 55. Predictions Argument Wildcarding
  56. 56. Predictions Argument Wildcarding • Argument::exact($value) • Argument::type($typeOrClass) • Argument::which($method, $value) • Argument::that(callback) • Argument::any() • Argument::cetera() • https://github.com/phpspec/prophecy#arguments-wildcarding
  57. 57. Array Mocks Generate
  58. 58. Array Mocks Generate
  59. 59. Array Mocks Red
  60. 60. Array Mocks Green (whoops!)
  61. 61. Array Mocks Green
  62. 62. Get Mock Object
  63. 63. Get Mock Object
  64. 64. Get Mock Object Generate
  65. 65. Get Mock Object Generate (whoops!)
  66. 66. Get Mock Object This is PHP, baby ???
  67. 67. Get Mock Object Right way
  68. 68. Best Practices IMHOs
  69. 69. Do not use TDD in simple CRUD applications (IMHO) • High cost • Slow (in terms of development time) • Zero profit • Use functional and integration tests instead
  70. 70. Do not mock 3rd party code • Large complicated tests • You actually test not how your code works with this library, but how your code works with your understanding of this library
  71. 71. Do not mock 3rd party code Use interfaces instead of 3rd party dependent code
  72. 72. Consider using appropriate DI library • symfony/di and Pimple are not well suited for TDD because of large amount of small classes • you must define rule for every class, which is very boring • There are some DI containers which will create most objects without explicitly defined rules by just reading constructor arguments type hints through reflection
  73. 73. Consider using appropriate DI library • zend-di • Laravel IoC Container - http://laravel.com/docs/ioc • PHP-DI - http://php-di.org/
  74. 74. phpspec at CI
  75. 75. phpspec junit formatter
  76. 76. Thank you! Questions?

×