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. 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. 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. 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. 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. 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. 4,5. DDD with Behat
● Not a BDD yet
● Not just acceptance tests with Behat
BDD
Behat
acceptance
tests
DDD with
Behat
10. Functional tests with Behat
https://github.com/diaspora/diaspora/blob/develop/features/desktop/change_email.feature
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. 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. 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)
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
http://www.infoq.com/presentations/model-to-work-evans
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
http://www.infoq.com/presentations/model-to-work-evans
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.
21. Domain Model
● Domain model is just Plain Old PHP Objects.
● Framework-agnostic
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.
http://martinfowler.com/eaaCatalog/domainModel.html
23. Forget all you know about
frameworks, controllers,
forms, api etc. Just do
OOP.
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. 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.
28. Scenario first
Do not think about implementation, think about
business value, use-cases and user stories
first.
29. Tip: personalize your users in scenarios, remember their names and other
private info and do not change them between scenarios
30. 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
31.
32.
33. 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.
34. 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
35.
36.
37.
38. Note: this is unusual situation. Doctrine
Entities should be used as Domain
Entities when possible.
39.
40.
41. Where is $em->flush()?
Avoid using $em->flush() at the domain model level. This is
against of UnitOfWork ideology
http://martinfowler.com/eaaCatalog/unitOfWork.html
54. 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)
60. 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)
