2. Advantages to Automating Testing
● Faster to test
○ Don't need to "click about"
○ Don't need to login
○ Don't need to have commented out test code
● Prevent recurring bugs
○ Write a test for bug, run the test after every change
● Easier to test edge cases
● Less fear when making changes
○ You may have forgotten how the code works
○ You may inherit someone else's code
● Find bugs before your users
○ This means you keep your customers happy, this
means more money!
3. Advantages to Automating Testing
● Better designed code, especially with TDD
○ Unit tested code tends to be
■ Less coupled
■ Less complex
● Tests document how code should work
● Once you are good at unit testing, it's
probably faster
● Tests don't have to be amazing: "Imperfect
tests, run frequently, are much better than
perfect tests that are never written at all"
4. Disadvantages
● You have to suck it up and write tests to
really see the benefits
● Hard to retrofit tests
○ You may have to refactor old code, or
○ You may have to write a lot of test code for code
which is not easy to test
● Harder to write bad code
● You probably won't want to write code
without tests again
5. Goals When Writing Tests
● Tests should be
○ Simple
■ Don't have ifs or loops
○ Easy to write
○ Easy to read
○ Easy to run
○ Isolated
● But these ideas may conflict or be hard to
achieve
○ Do your best
○ Can improve tests over time
○ Bad tests better than no tests
6. Common PHPUnit Methods
● $this->assertTrue($value, 'Value should
have been true')
● $this->assertFalse($value, 'Value should
have been false')
● $this->assertEquals($expected, $actual,
'The result is not what was expected')
● Try to write a message to indicate what
specifically is being asserted
○ Easier to understand what's wrong instead of e.g.
"Failed asserting that false is true"
7. Common PHPUnit Patterns
● Use setUp() method to instantiate the class
you are testing
○ This works well if you don't have lots of constructor
parameters
● Use data providers to test lots of different
inputs
○ Tests shouldn't have duplicate code either
● Use tearDown() method if you need to clean
up external resources after each test is run
○ Files
○ Database
8. Hard to Test Things
● Static calls to other classes
○ You cannot mock the dependency
● Singletons
○ Constructor is private or protected
○ Uses static call to get instance
○ Cannot guarantee there are no side effects when
running multiple tests
● Private methods
○ Usually you indirectly test these when you test public
methods
○ Can use reflection if you really want, but this
probably means you should refactor
9. Hard to Test Things
● Hard coded dependencies
○ Such as when a class instantiates another class
● Magic methods
○ __call
○ __get
○ __set
10. How to Write Testable Code
● Use dependency injection
○ This means you don't instantiate classes unless
you're in a factory
● Keep methods relatively small
● Avoid having lots of private methods
● Write classes which do one thing (single
responsibility principle)
11. Go go go!
● http://www.phpunit.
de/manual/current/en/index.html