Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Phpers day 2019

184 views

Published on

evelopment of Behat and PHPSpec tools cause, that BDD started to show up in minds of PHP developers. How we currently understand this methodology? Is it become effective and helpful in our everyday work? What problems and fails we can meet during tries of applying this methodology to our project?

During this talk, you will see how we can use BDD for modeling our application. One of the benefits will be an application that is not hardly coupled with the framework. So, it will give you the possibility of easy integration with that kind of tool. Also integrating with other infrastructure elements will be easy to implement. Everything thanks to use of ports and adapters approach.

Published in: Technology
  • Be the first to comment

Phpers day 2019

  1. 1. BDD design your application decoupled from framework Dariusz Drobisz PHPers Day Gdańsk 2019, 2.03.2019
  2. 2. About me ● PHP developer ● Framework agnostic enthusiast (but Symfony lover) ● BDD practitioner ● Event Storming interested ● PHPers organiser ● working fordariusz.drobisz@gmail.com @daryush_d
  3. 3. BDD Behavior Driven Development
  4. 4. What is not BDD? ● Behat ● PHPSpec ● Gherkin scenarios ● Tests
  5. 5. What is not BDD? ● Behat ● PHPSpec ● Gherkin scenarios ● Tests ● Brick Driven Development
  6. 6. What is not BDD? ● Behat ● PHPSpec ● Gherkin scenarios ● Tests ● Brick Driven Development (thx @chrisholland)
  7. 7. “Behaviour-driven development is about implementing an application by describing its behaviour from the perspective of its stakeholders” - Dan North
  8. 8. So what is BDD? Describing application behaviour
  9. 9. So what is BDD? Stakeholders perspective
  10. 10. TDDWhat BDD is?
  11. 11. TDD 2.0What BDD is?
  12. 12. Why not just TDD? Hard to test something that doesn’t exists.
  13. 13. Why not just TDD? Easier to design behaviour than test something that you don’t have.
  14. 14. Why not just TDD? Language matters… … and helps to design.
  15. 15. 2 levels of BDD StoryBDD SpecBDD
  16. 16. Story BDD ● Describing high level business application behaviour. ● Helps to elaborate what the needs are ● Helps communicate with business ● Helps to elaborate common language ● Gives us scenarios that can (and should) become automated functional tests
  17. 17. Spec BDD ● Describing low level implementation behaviour ● To design our code ● To design how it communicate ● Helps understand what code is doing ● Helps get back to your code after while
  18. 18. BDD - tools ● Spec: ○ PHPSpec ○ Spec classes with examples ● Story ○ Behat ○ Scenarios written in gherkin language ○ Automation of scenarios in context classes
  19. 19. Problematic part Story BDD
  20. 20. What's the problem? Mr. Story BDD? Let’s describe everything!
  21. 21. Let’s describe everything! ● every link click ● every input fill ● every automatically generated crud ● every screen generated by some admin bundle ● EVERYTHING! **That applies also to Spec BDD**
  22. 22. What's the problem? Mr. Story BDD? Technical scenarios!
  23. 23. People think how Not what and why
  24. 24. Technical scenarios!
  25. 25. Technical scenarios!
  26. 26. What's the problem? Mr. Story BDD? How to automate?
  27. 27. How to automate? User Interface vs Code level
  28. 28. How to automate? With infrastructure vs Without infrastructure
  29. 29. Let’s forget!
  30. 30. Let’s forget that we are developing web application!
  31. 31. Let’s start solve business problems.
  32. 32. Example Design with BDD How I do that
  33. 33. Feature/scenario
  34. 34. Given steps Let’s make some preparation
  35. 35. We have nothing - let’s start think up
  36. 36. Is it worth to spec?
  37. 37. Let’s implement that
  38. 38. Let’s store that somewhere
  39. 39. What is this repository? DB one?
  40. 40. We don’t know. It’s our port.
  41. 41. We can’t instantiate interface
  42. 42. Let’s have some infrastructure
  43. 43. The fast one!
  44. 44. First adapter of our port
  45. 45. Let’s now use this adapter
  46. 46. Same with another step
  47. 47. Date assumption
  48. 48. Current codebase state
  49. 49. Assumptions works
  50. 50. When steps Put some action there
  51. 51. Application layer introduction
  52. 52. Command - another port
  53. 53. How command looks like?
  54. 54. Command need to be handled - how?
  55. 55. Something need to happen. Maybe we can spec that?
  56. 56. Handler spec - what we already know
  57. 57. Let’s think up rest
  58. 58. We can implement what we designed
  59. 59. We design something in our port
  60. 60. Let’s implement that in adapter
  61. 61. Let’s design borrowing recording
  62. 62. Implementation
  63. 63. Specs works
  64. 64. Get back to behat context
  65. 65. Then steps Check some results
  66. 66. Results checking
  67. 67. Results checking
  68. 68. Behat is green
  69. 69. Behat is green
  70. 70. And here we have fully functional piece of application without framework
  71. 71. Integration Did I mention that I’m a Symfony lover?
  72. 72. Application layer used in controller
  73. 73. Doctrine mapping
  74. 74. Doctrine adapter for port
  75. 75. Final structure
  76. 76. Repository https://github.com/daryush/PHPersDay2019
  77. 77. Further actions examples ● using command bus ● encapsulate transactions ● validation on framework side ● dispatching events ● integration tests
  78. 78. Summary ● BDD helps with design process ● framework agnostic application is easy to integrate ● testability ● understand of business ● understand of development process ● ability to postpone infrastructure decisions
  79. 79. Questions? Thank you dariusz.drobisz@gmail.com @daryush_d https://joind.in/talk/6e31d

×