An introduction to test driven development with PHP and Laravel.

1. TEST DRIVEN
DEVELOPMENT WITH
LARAVEL
By: Tyler Johnston
@tylerjohnst

2. HI, I’M TYLER
• Owner at Ahoy Consulting
• Mostly Ruby and Javascript, sometimes
PHP, sometimes iOS and sometimes
Android.
• Organizer of Suncoast.js Meetup Group
(You should come!)
• Find me on the Twitters: @tylerjohnst

3. WHAT IS TDD?
• TDD is the practice of software development
guided by tests.

4. STORYTIME

5. WHY TDD?
• What does TDD accomplish?
• Code Confidence
• Cleaner Code
• Fewer Bugs

6. CODE CONFIDENCE
You should be confident in your code. You as
the rockstar developer, designer, devops and
unicorn should be able to deploy your master
branch at any time with full certainty that it
works 100%.

7. CLEANER CODE
• Tests give you live feedback of your API.
• Are the tests hard to write?
• Are the tests breaking constantly?
• “This code is untestable”

8. CLEANER CODE
Only build the features that you need. When
you are only writing tests for functionality you
need, it can help you avoid “over-engineering”
such as building things you “might” need in the
future.

9. CLEANER CODE
Separate interface from implementation
thinking. You may have a tendency to pollute
API design decisions with implementation
speculation.

10. CLEANER CODE
• Software development is a never ending
process. Best practices change, patterns
change, business requirements change. Tests
allow you to adapt to this.
• Tests allow you to change or refactor your code
at any given time without changing the
interfaces to your objects.
• Changes to the system should not be painful.
A fully tested system can be changed without
fear. Breaking an API should cause tests to fail.

11. BUT ISN’T TDD SLOWER
• Yes, but that’s a good thing.
• “What the research team found was that the
TDD teams produced code that was 60 to 90
percent better in terms of defect density than
non-TDD teams. They also discovered that
TDD teams took longer to complete their
projects—15 to 35 percent longer.”
• Source: http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

12. I’m ready. Lets get started!

13. RULES OF TDD BY UNCLE
BOB MARTIN
• You may not write any production code
without a failing test
• You may not write more of a test than is
sufficient to fail
• You may not write more production code
than is sufficient to pass

14. THE TDD CYCLE

15. RED - Write a failing test
GREEN - Write the minimal amount of
code required to make the test pass
REFACTOR - Clean up any duplication
and make any code clarity changes
while ensuring that the test still passes.
REPEAT

16. GETTING STARTED WITH
LARAVEL
• Almost no work to get started! Laravel ships
with PHPUnit configured! (See phpunit.xml).
Hooray!

17. RUNNING YOUR TESTS
• Download the PHPUnit.phar package, add it
to your path. Run it and see:

18. TEST FRAMEWORKS
• There are a variety of test frameworks for
PHP. I’m using PHPUnit because it ships
with Laravel and I’m really lazy and easily
frustrated with dev tools.
• PHPUnit, PHPSpec, SimpleTest, etc.

19. WHAT TO TEST?
• The hardest thing about Test Driven
Development is writing your first test.
• Break the feature in to small bite sized parts.
Write a failing test for that small part.

20. EXAMPLE
I’m designing an car wash management tool for my
dealership. I need to track if and when a car needs a car
wash.

21. OUR FIRST FAILING TEST
r failure can be considered a failing test. A test suite that doesn’t

22. WRITE THE MINIMUM AMOUNT
OF CODE TO MAKE THE TEST
PASS

23. AND OUR TEST NOW
PASSES

24. REFACTOR
• Nothing to refactor yet. Lets add the other
test to make sure both ways work.

25. FAILING TEST
A car has an age. Lets write a test to be able to check that.

26. BACK IN THE RED

27. MAKE THE TEST PASS

28. ALL GREEN!

29. REFACTOR

30. REFACTOR
Tests should also be refactored to reduce duplication.

31. AND THE TESTS STILL
PASS!

32. FAILING TEST
Now we need the ability to set the age of the car.

33. AND IT FAILS

34. WRITE THE CODE

35. AND IT PASSES

36. REFACTOR
Looks pretty good, I don’t think we need to refactor.

37. FAILING TEST

38. AND THE TEST FAILS

39. MAKE THE TEST PASS

40. RUN THE TESTS, IN THE
GREEN!

41. REFACTOR

42. AND WE STILL PASS!

43. CELEBRATION!
We’ve done it! Our first set of tests are done!

44. I’M REALLY READY TO GO.
WHAT DO YOU DO?
• I’m pretty opinionated on how I do testing
and design.
• Feel free to use your own programming
patterns and idioms.

45. MODELS
• I tend to only test things that I do with the
data. Laravel is a tested and well worn
framework. I almost never test database
interactions unless I am doing my own
custom SQL or modifying getter/setter
attributes.
• Your models fetch and transform data. Test
the transformation and conversions, not the
DB access.

46. CONTROLLER
• I keep my controllers very skinny. They are
limited to:
• Fetching, creating, and updating Models.
• then
• Renders views or redirects to other
controller actions.

47. VIEWS
• I don’t test views. At all. Maybe one or two
sanity checks but the controller “integration”
style tests will cover the view actually
rendering.
• (If a view throws an exception, it will be
caught from your controller tests)
• View tests end up extremely brittle. A
designer goes in and changes a class name
or ID attribute or even heirarcy and your
tests are now broken.

48. VIEWS CONT.
• The better solution (in my opinion) is to use
the presenter pattern.
• No method calls from the view should
interact with anything other than presenters.
• Write tests for your presenters and now your
views are completely tested!

50. PRESENTERS
• Any types of transformation to user visible
strings.
• implode(‘ ‘, [$user->first_name, $user-
>last_name]);

51. THANK YOU!
Questions?
@tylerjohnst on the Twitters