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.

1. BDD
design your application decoupled from framework
Dariusz Drobisz
PHPers Day Gdańsk 2019, 2.03.2019

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. BDD
Behavior Driven
Development

4. What is not BDD?
● Behat
● PHPSpec
● Gherkin scenarios
● Tests

5. What is not BDD?
● Behat
● PHPSpec
● Gherkin scenarios
● Tests
● Brick Driven Development

6. What is not BDD?
● Behat
● PHPSpec
● Gherkin scenarios
● Tests
● Brick Driven Development (thx @chrisholland)

7. “Behaviour-driven development
is about implementing an
application by describing its
behaviour from the perspective
of its stakeholders”
- Dan North

8. So what is BDD?
Describing application
behaviour

9. So what is BDD?
Stakeholders perspective

10. TDDWhat BDD is?

11. TDD 2.0What BDD is?

12. Why not just TDD?
Hard to test something that doesn’t exists.

13. Why not just TDD?
Easier to design behaviour than test something
that you don’t have.

14. Why not just TDD?
Language matters…
… and helps to design.

15. 2 levels of BDD
StoryBDD
SpecBDD

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. 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. BDD - tools
● Spec:
○ PHPSpec
○ Spec classes with examples
● Story
○ Behat
○ Scenarios written in gherkin language
○ Automation of scenarios in context classes

19. Problematic part
Story BDD

20. What's the
problem?
Mr. Story BDD?
Let’s describe
everything!

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. What's the
problem?
Mr. Story BDD?
Technical
scenarios!

23. People think how
Not what and why

24. Technical scenarios!

25. Technical scenarios!

26. What's the
problem?
Mr. Story BDD?
How to automate?

27. How to automate?
User Interface
vs
Code level

28. How to automate?
With infrastructure
vs
Without infrastructure

29. Let’s forget!

30. Let’s forget that we
are developing web
application!

31. Let’s start solve
business problems.

32. Example
Design with BDD
How I do that

33. Feature/scenario

34. Given steps Let’s make some preparation

35. We have nothing - let’s start think up

36. Is it worth to spec?

37. Let’s implement that

38. Let’s store that somewhere

39. What is this
repository? DB one?

40. We don’t know.
It’s our port.

41. We can’t instantiate interface

42. Let’s have some infrastructure

43. The fast one!

44. First adapter of our port

45. Let’s now use this adapter

46. Same with another step

47. Date assumption

48. Current codebase state

49. Assumptions works

50. When steps Put some action there

51. Application layer introduction

52. Command - another port

53. How command looks like?

54. Command need to be handled - how?

55. Something need to
happen.
Maybe we can spec
that?

56. Handler spec - what we already know

57. Let’s think up rest

58. We can implement what we designed

59. We design something in our port

60. Let’s implement that in adapter

61. Let’s design borrowing recording

62. Implementation

63. Specs works

64. Get back to behat context

65. Then steps Check some results

66. Results checking

67. Results checking

68. Behat is green

69. Behat is green

70. And here we have
fully functional piece
of application
without framework

71. Integration Did I mention that I’m a Symfony
lover?

72. Application layer used in controller

73. Doctrine mapping

75. Doctrine adapter for port

76. Final structure

77. Repository
https://github.com/daryush/PHPersDay2019

78. Further actions
examples
● using command bus
● encapsulate transactions
● validation on framework side
● dispatching events
● integration tests

79. 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

80. Questions?
Thank you
dariusz.drobisz@gmail.com
@daryush_d
https://joind.in/talk/6e31d