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.

DDD with Behat


Published on

Published in: Software
  • Hello there! Get Your Professional Job-Winning Resume Here!
    Are you sure you want to  Yes  No
    Your message goes here

DDD with Behat

  1. 1. DDD with Behat by Anton Serdyuk
  2. 2. Agile project and team evolution 1 2 3 4 5 6
  3. 3. 1. No tests at all ● You can write very good code, but this code WILL suck later ● “Refactoring” is a swearword ● That is why constant “No time for refactoring” ● “We need to rewrite it from scratch” at the end 1 2 3 4 5 6
  4. 4. 2. So called “Unittests” ● Not actual unittests ● xUnit based tests for controllers, entities, repositories etc without any order ● Complex fixtures ● Hard to support ● “There is no time for tests” because of no visible profit 1 2 3 4 5 6
  5. 5. 3. Selenium acceptance tests ● Written by QA automators usually in Java even in PHP and .NET projects ● This approach is widely spread, well known and may perform well, but I think autotests implementation is not a QA job 1 2 3 4 5 6
  6. 6. 4. Behat acceptance tests ● This approach may perform very well ● Can be written by QA (and even sometimes by BA) ● Some people call it BDD, but it is not BDD actually Given there is registered user Bob And I am on homepage When I follow “Sign Up” And I fill “Bob” in “Username” And I press “Sign Up” Then I should see “This username is already in use” 1 2 3 4 5 6
  7. 7. 5. BDD ● BDD is not about tests ● It is the process of finding out and delivering features which provide value to users ● Should be used not only in dev team but in whole team beginning from Product Owner Given there is registered user Bob When I try to sign up with username “Bob” Then I should get error that this user is already signed up 1 2 3 4 5 6
  8. 8. 6. Lean ● The last point of Agile team and project journey ● It is all about how to deliver more value to customer and how to build sustainable business around this product 1 2 3 4 5 6
  9. 9. 4,5. DDD with Behat ● Not a BDD yet ● Not just acceptance tests with Behat BDD Behat acceptance tests DDD with Behat
  10. 10. Functional tests with Behat
  11. 11. They are really cool ● Provide Continuous Integration and Continuous Delivery possibility ● Easy to write ● Can be written by QA and even sometimes by BA
  12. 12. But... ● Long execution time ○ Less green builds ○ Wasted developers’ time ● Non-deterministic failures ○ Developers try to rebuild every failing build instead of investigating ○ Wasted developers’ time
  13. 13. But... ● They are too specific ○ It is difficult to dig up business value from them ○ less benefits for use by (and with) business people (BA, Product Owner)
  14. 14. DDD can help
  15. 15. Model Model is a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to this domain
  16. 16. Ubiquitous Language A language structured around the domain model and used by all team members to connect all the activities of the team with the software
  17. 17. Ubiquitous Language helps to find out model weaknesses If domain expert does not understand you when you use ubiquitous language, then your model does not describe domain as needed and should be corrected.
  18. 18. Multilayered Architecture
  19. 19. Layers in typical symfony2 project ● Infrastructure ○ Doctrine ○ SwiftMailer ● UI ○ views ○ JS ● Application ○ controllers ○ some services ● Domain ○ entities
  20. 20. Entities are not enough to create a powerful domain model
  21. 21. Domain Model ● Domain model is just Plain Old PHP Objects. ● Framework-agnostic
  22. 22. Domain Model At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it's this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form.
  23. 23. Forget all you know about frameworks, controllers, forms, api etc. Just do OOP.
  24. 24. Behat can be used to drive Domain Model code
  25. 25. Warning This is real project code, so it is not ideal and can be possibly done better. But in real project we can not refactor our code infinitely because of obvious reasons.
  26. 26. Sample user private messages functionality ● Registered user can send private message to any other registered user ● Messages should be combined to dialogs ● There should be email notifications about new messages
  27. 27. Scenario first Do not think about implementation, think about business value, use-cases and user stories first.
  28. 28. Tip: personalize your users in scenarios, remember their names and other private info and do not change them between scenarios
  29. 29. Note: I forgot about last message text in dialogs, and it will be added later. Note: “fetch messages” operation is part of our domain, because we want to know when to mark messages as read. So it should be explicitly added to the scenario
  30. 30. Note: Maybe it would be better to split this scenario to 1) total number of unread messages should be decreased; 2) message should not be unread when I fetch messages second time.
  31. 31. Note: Maybe it would be better to move last message text to dialog “properties” (see note to “I can send messages” scenario). Or we should remove “last message date” from dialog instead
  32. 32. Note: this is unusual situation. Doctrine Entities should be used as Domain Entities when possible.
  33. 33. Where is $em->flush()? Avoid using $em->flush() at the domain model level. This is against of UnitOfWork ideology
  34. 34. Notifications
  35. 35. Simple and framework agnostic Domain Model ● Easy to write ● Easy to read and understand ● Can be guided by UnitTests if they have complex logic ● Easy to migrate between frameworks (if you want to migrate, for example, from symfony2 to silex + AngularJS)
  36. 36. Application and UI layers
  37. 37. Domain scenarios steps can easily be reused in UI tests
  38. 38. Profit ● Everything needed by business can be done without a single Controller line ● Simple and clear integration tests can be used as user stories by business people ● Simple and thin controllers will not contain business rules ● Little amount of complex and heavy UI tests (no need to test business expectations, only UI itself)
  39. 39. Thanks!