Win at Life
  with Unit Testing.
   by Mark Story
Who is this goofball

Art college graduate that needed to make
money.

CakePHP core contributor for 2.5 years.
Developer of DebugKit, ApiGenerator and
several other plugins.

Lead front end developer at FreshBooks
Can unit testing
   make me
  awesome?
Hell yes.
Why write tests?

Helps ensure things that did work, still do.
Helps reduce time it takes to fix new
defects.
Helps you plan a design, showing you
where it might be complicated or overly
coupled.
Living documentation.
...


Catch issues earlier.
Increased developer confidence.
Automated killer robots.
What to test?

Code that keeps you up at night.
Code that involves real money.
Code that has broken before.
Code that is tedious to test manually.
Different flava’s


Unit tests
Functional or Integration tests
Unit Tests

Testing the smallest parts of your
application in isolation.
Often testing single methods or single
functions.
Generally uses many mocks.
Really useful when doing Test driven
development.
Functional Tests

Tests pieces working well together.
Test top level objects to ensure all their guts
are working together.
Tests hitting database fixtures are often
functional tests.
Functional tests run slower, but use more
active code.
Challenges of testing

 Time. It takes time to write tests. But it
 takes more time to fix the same bugs later
 multiple times.
 Only shows the presence of issues, not the
 absence.
 Only catches errors you have tests for.
Benefits of testing

Find problems earlier.
Can be automated, robots are helpful.
Less manual testing.
Easier to ensure requirements are met.
Unicorns.
The End.
Of the part where I extol the winsauce tests
                can bring.
Mock objects
<insert>A funny joke</insert>
Mocks and test
      doubles
Writing isolated tests is hard. Mock objects
make it easier.
Mocks help ensure your objects are
touching other objects in the right places.
Mocks help you stub out behaviour before
you write the real deal.
Can I use a mock
       for:
     Global functions?
   Stuff not in functions?
No.
When to use mocks

When talking to the outside world.
  Email.
  Webservices (Twitter, Paypal, YouTube).
  Writing files to disk.
  Writing to the database.
...


When you want to ensure two objects are
working together properly.
When you do want to isolate problems.
Mocking your code

Make sure dependencies can be replaced at
runtime.
 Constructor injection.
 Factory methods.
 Setter methods.
Constructor Injection

 Accept objects your object depends on in
 the constructor.
 Jam mocks in when testing.
Factory Factory
      Factory
Factory methods can be overridden in
subclasses to return mocks.
Setter method
Allows post construction modification of
internal dependencies.
Mocks in the house


Mocks can be critical of a test subject.
Mocks and stub out dangerous
components, or methods.
Critical mocking
Critic mocks check that other objects touch
them correctly.
Stub danger.
You can stub methods that send headers or
touch the outside world.
Stub expensive stuff.
 Mocks can be used to stub network
 resources or expensive to fetch results.
In conclusion


Mocks help make tests run faster, and
require less setup & teardown.
They allow you to write true unit tests.
The End.
(of the part where I blabber about mocks)
Automated Killer
    Robots
 test automation for squishy humans.
Automated testing.


Tests that are never run, are as good as
deleted.
Build servers to the rescue!
Hudson

Hudson is a continuous integration server
built in Java.
Has a great plugin community.
Can send emails, Jabber and give pithy
Chuck Norris quotes.
...


Can be configured to run on a schedule or
post commit.
Integrates well with SVN and there is a GIT
plugin too.
Typical Hudson setup

 Run tests on each commit/push.
 Run all tests again each night, incase there
 was a slow day.
 Nightly builds are also a good time to run
 code coverage builds.
Setting Hudson up


Go to http://hudson-ci.org
wget http://hudson-ci.org/latest/hudson.war

java -jar hudson.war
Hudson dashboard
Hudson dashboard
Hudson dashboard
Hudson dashboard
Hudson project
The End.
For real this time.
Questions?

Win at life with unit testing

  • 1.
    Win at Life with Unit Testing. by Mark Story
  • 2.
    Who is thisgoofball Art college graduate that needed to make money. CakePHP core contributor for 2.5 years. Developer of DebugKit, ApiGenerator and several other plugins. Lead front end developer at FreshBooks
  • 3.
    Can unit testing make me awesome?
  • 4.
  • 5.
    Why write tests? Helpsensure things that did work, still do. Helps reduce time it takes to fix new defects. Helps you plan a design, showing you where it might be complicated or overly coupled. Living documentation.
  • 6.
    ... Catch issues earlier. Increaseddeveloper confidence. Automated killer robots.
  • 7.
    What to test? Codethat keeps you up at night. Code that involves real money. Code that has broken before. Code that is tedious to test manually.
  • 8.
  • 9.
    Unit Tests Testing thesmallest parts of your application in isolation. Often testing single methods or single functions. Generally uses many mocks. Really useful when doing Test driven development.
  • 10.
    Functional Tests Tests piecesworking well together. Test top level objects to ensure all their guts are working together. Tests hitting database fixtures are often functional tests. Functional tests run slower, but use more active code.
  • 11.
    Challenges of testing Time. It takes time to write tests. But it takes more time to fix the same bugs later multiple times. Only shows the presence of issues, not the absence. Only catches errors you have tests for.
  • 12.
    Benefits of testing Findproblems earlier. Can be automated, robots are helpful. Less manual testing. Easier to ensure requirements are met. Unicorns.
  • 13.
    The End. Of thepart where I extol the winsauce tests can bring.
  • 14.
  • 15.
    Mocks and test doubles Writing isolated tests is hard. Mock objects make it easier. Mocks help ensure your objects are touching other objects in the right places. Mocks help you stub out behaviour before you write the real deal.
  • 16.
    Can I usea mock for: Global functions? Stuff not in functions?
  • 17.
  • 18.
    When to usemocks When talking to the outside world. Email. Webservices (Twitter, Paypal, YouTube). Writing files to disk. Writing to the database.
  • 19.
    ... When you wantto ensure two objects are working together properly. When you do want to isolate problems.
  • 20.
    Mocking your code Makesure dependencies can be replaced at runtime. Constructor injection. Factory methods. Setter methods.
  • 21.
    Constructor Injection Acceptobjects your object depends on in the constructor. Jam mocks in when testing.
  • 22.
    Factory Factory Factory Factory methods can be overridden in subclasses to return mocks.
  • 23.
    Setter method Allows postconstruction modification of internal dependencies.
  • 24.
    Mocks in thehouse Mocks can be critical of a test subject. Mocks and stub out dangerous components, or methods.
  • 25.
    Critical mocking Critic mockscheck that other objects touch them correctly.
  • 26.
    Stub danger. You canstub methods that send headers or touch the outside world.
  • 27.
    Stub expensive stuff. Mocks can be used to stub network resources or expensive to fetch results.
  • 28.
    In conclusion Mocks helpmake tests run faster, and require less setup & teardown. They allow you to write true unit tests.
  • 29.
    The End. (of thepart where I blabber about mocks)
  • 30.
    Automated Killer Robots test automation for squishy humans.
  • 31.
    Automated testing. Tests thatare never run, are as good as deleted. Build servers to the rescue!
  • 32.
    Hudson Hudson is acontinuous integration server built in Java. Has a great plugin community. Can send emails, Jabber and give pithy Chuck Norris quotes.
  • 33.
    ... Can be configuredto run on a schedule or post commit. Integrates well with SVN and there is a GIT plugin too.
  • 34.
    Typical Hudson setup Run tests on each commit/push. Run all tests again each night, incase there was a slow day. Nightly builds are also a good time to run code coverage builds.
  • 35.
    Setting Hudson up Goto http://hudson-ci.org wget http://hudson-ci.org/latest/hudson.war java -jar hudson.war
  • 36.
  • 37.
  • 38.
  • 39.
  • 40.
  • 41.
  • 42.