Unit testing in CakePHP

Making bullet resistant code.

 Goals for next hour

• If you are not familiar with Unit Testing,

introduce you to the concepts and practices of
Unit testing.

• If you are familiar with Unit Testing, show how

it works in CakePHP.

• Show you how to make and run tests and some

extra spice on the side.
 So who is this guy?
• 4 Years PHP experience.
• 1.5 Years CakePHP experience.
• Member of Core development team since May
2008.

• Developer: Cake Development Corporation.

• Blogger: http://mark-story.com.
• Designer of all kinds of things.
 Co-Authored by:

• Tim Koschuetzki from Berlin, Germany.

• Alias “DarkAngelBGE”.
• Blogger: debuggable.com.
• Entrepreneur: Debuggable Ltd.
• 5 years PHP experience.
• 1.5 years CakePHP experience
 Unit Testing?
• Unit tests are automated procedure that ensure
the software you write, works the way you
think it does.

• Unit = the smallest part of your application

• In procedural programming these would be
your functions

• In OOP programming these are your Object's

methods.
Testing is like making coffee

• Coffee grinds + water (inputs)

• Coffee making magic (function)
• Hot Coffee (output)
• Our tests would ensure that the
coffee is black and hot and
delicious.
 Testing is an automated
process
• Tests can be run repeatedly and
always work the same.

• Tests shouldn't require additional

configuration.

• Tests can be grouped or run

individually.

• Green is your friend, Red is not.

Making assertions
Making assertions
 SimpleTest example

• We have a function that censors text and

replaces the banned words with ****

removeBannedWords($text, $banned)

• $text – Text to censor

• $banned – array of words to ban.
SimpleTest example
SimpleTest example
SimpleTest example
SimpleTest example
SimpleTest example
SimpleTest example
 Fail?

• Red bar means that a test has failed

• When a test fails, a message informs you of the
expectation that was not met, and on which line
that expectation can be found.

• Red bars appear anytime there are any errors /

uncaught exceptions or failing tests.
Is our function broken?
 Pass-tastic!

• Green bar means everything is working as we

planned.
 Benefits of Unit Testing

• Know when a changeset breaks the expected

behavior.

• Creates living documentation.

• Bug fixing is much easier, faster and less prone
to creating new bugs.

• Faster than browser testing.

• Easy to repeat.
 Benefits of Unit Testing

• Reduces developer hesitation to refactor code.

• Catch bugs earlier.
• Increase developer confidence.
• Reduce the need to manually test things.
 Limitations of Unit Testing

• Time: Time is money and tests take time to

write.

• Motivation: Testing is anti-lazy.

Sometimes
tests for Objects are longer than object code.

• Maintenance: More code to maintain. For

example CakePHP code base (1/3 code, 2/3
tests)
 Limitations of Unit Testing

• Doesn't catch programmer errors, for example

reading the specs wrong.

• Only shows the presence of errors not the

absence of them.

• Only catches errors you have tests for. If a

situation isn't covered, testing will not catch
any problems with it.
 So why write Unit Tests?

• Increase developer confidence - You can be certain

that you have done what was required.

• Increase overa" quality - You have additional

confidence that your project is functioning
properly

• Find problems earlier - I personally have found

many problems with implementations while I
write tests.
 So why write Unit Tests?

• Reduce time lost click testing - Click testing is slow

and tedious. Much of this time can be replaced
with automated unit tests.

• Reduce 'voodoo' factor - Since you have proven

uses for your code you are less afraid to rebuild
that ugly function and make it more useful.
Unit Testing in CakePHP
 Unit Testing in CakePHP

• Download and install SimpleTest

• http://simpletest.org

• Place in app/vendors or cake/vendors

• Set debug >= 1

• Add $test Database connection.

• Visit path/to/app/test.php
 Test Cases & Test Groups
Test Cases Test Groups

• Contain tests for • Way to run multiple tests at

individual classes. once.

• Collections of test • Allow you to test a subsystem

methods. or collection of objects

• ex. Menu Component, • Free group test called 'All tests'

User Model
• ex. All models, Access Control
system, payment processing
File layout
• in app/tests
• Different case
directories for
different objects.
 Filename conventions
Test Cases
• Underscored and lowercase

• users_controller = users_controller.test.php

• post = post.test.php

Group Tests
• Underscored and lowercase but any name

• models.group.php

• payment_processing.group.php
Classes involved

You
Classes involved

You
Classes involved

SimpleTest

UnitTestCase

WebTestCase

Mock

SimpleSocket

You SimpleTest
Classes involved

SimpleTest

UnitTestCase

WebTestCase

Mock

SimpleSocket

You SimpleTest
 Classes involved

CakePHP Test Suite SimpleTest

CakeTestCase UnitTestCase

CakeWebTestCase WebTestCase

CakeTestFixture Mock

CakeTestModel SimpleSocket

You SimpleTest
 Classes involved

CakePHP Test Suite SimpleTest

CakeTestCase UnitTestCase

CakeWebTestCase WebTestCase

CakeTestFixture Mock

CakeTestModel SimpleSocket

You SimpleTest
 Classes involved

CakePHP Test Suite SimpleTest

CakeTestCase

CakeWebTestCase WebTestCase

CakeTestFixture Mock

CakeTestModel SimpleSocket

You SimpleTest
 Classes involved

CakePHP Test Suite SimpleTest

CakeTestCase

CakeWebTestCase

CakeTestFixture Mock

CakeTestModel SimpleSocket

You SimpleTest
 CakeTestCase

• Test case class that all App and Core test cases
should extend.

• CakeTestCase adds several useful features to

UnitTestCase
 CakeTestCase Methods
• before($method) • Announces the start of a
test method.

• after($method) • Announces the end of a

test method.

• start() • First method called in a

test case.

• end() • Last method called in a

test case.
 CakeTestCase Methods
• startTest($method) • Called just before a test
method is executed.

• endTest($method) • Called just after a test

method has completed.
 CakeTestCase Methods
• startCase() • Called before a test case
is started.

• endCase() • Called after a test case

has run.
 CakeTestCase Methods

testAction($url, $params);

• Run a controller action and get the results.

• result: Whatever the action returns. Also simulates a
requestAction()

• view: The rendered view, without the layout

• contents: The rendered view, within the layout.

• vars: the view vars

 CakeTestCase Methods
assertTags($result, $expected)

• Allows you to compare HTML/XML

snippets to an array of expected values

getTests()

• Useful when debugging a specific case.

Check the implementation in CakeTestCase
before overriding.
CakeTestCase Method Order
CakeTestCase Method Order
Avoid setUp() & tearDown()

• When testing Models or using fixtures.

• Use startTest() and endTest() instead.

• setUp() & tearDown() run before start()

which is where the fixtures are first created.

• Using setUp() & tearDown() will cause errors

when testing models.
 Fixtures - Predictable data
• Fixtures create test database tables and records, which
you run tests against.

• A predictable and known application state is

vital to testing.

• Helps ensures that inputs will always produce the same

outputs given the same functionality of methods.

• Fixtures will use the $test connection if available. If

not they will use $default with a test_suite prefix.
 What is a Fixture?

• Fixture provides table schema and records to

fill the table.

• Each table is a separate fixture.

• Schema and Records can be inside the fixture
or imported from development data.
 Life of a Fixture
• Fixture tables are created in
CakeTestCase::start()

• Before each test method, fixture tables are

populated with records in fixture.

• After each test method, fixture tables are

truncated.

• Fixture tables are dropped in

CakeTestCase::end()
 Fixture field definitions

type:

• string (maps to VARCHAR)

• text (maps to TEXT)
• integer (maps to INT)
• float (maps to FLOAT)
• datetime (maps to DATETIME)
 Fixture field definitions
• key: set to primary to make the field
AUTO_INCREMENT, and PRIMARY KEY for the
table.

• length: set to the specific length the field

should take.

• null: set to either true (to allow NULLs) or false

(to disallow NULLs)

• default: default value the field takes.

Sample Fixture
Sample Fixture
Sample Fixture
 Import fixtures

• You can import the records of your current

database as well.

• Can choose to only import table structure, but

define records yourself. Or import both.

• Import by model or table and connection.

 Importing Fixtures

Import from a table and duplicate the records.

Importing Fixtures
 Importing Fixtures

Import from a model, and duplicate the records.

Importing Fixtures
 Importing Fixtures

Import model with shadow connection.

 To import or not?

• Importing records ties your tests to your

development data. Can make for lots of
broken tests.

• Writing many records out in fixture can take

extra time.
Putting it all together
Testing Models
Example Model
Test Case setup
Test Case setup
Test Case setup
Test Case setup
Test Case setup
Test Case setup
Test Case setup
 Model testing tips
• Using ClassRegistry::init() and the benefits over
new Widget()

• useDbConfig changed, and all relations built properly as well!

• No need for test model classes in most instances.

• Isolate tests with ClassRegistry::flush()

• Object states are persisted between test cases in the
ClassRegistry.

• ClassRegistry::flush() tosses those objects in the bin.

giving you a clean slate for each test.
 The importance of fixtures

• Fixtures allow you to avoid having to mock out

your database connections.

• Fixtures allow for known data, making your

tests invulnerable to application data
anomalies.

• Easily create data to cover any cases you want.

Unit tests vs. Functional tests

• In pure unit testing everything not being tested

is mocked.

• The example given and all the core model tests

are better classified as functional tests.

• Functional tests, test a slice of an application.

• These tests run slower, but give a more
complete test.
Testing Helpers
and using assertTags()
 Asserting Helper output

• Testing HTML is a pain. But must be done.

• Can use assertPattern() with insane regular
expressions.

• However, you will curse regular expressions as

they quickly become impossible to read and
understand.
Regular Expression vs.
assertTags()
Regular Expression vs.
assertTags()
 assertTags() tips
• Assertion must be for entirety of output.
• Order of attributes doesn’t matter
• Contents of attributes are case and whitespace
sensitive.

• Watch your keys, wrap multiple keys in array()

• Use true as third parameter for extra debug
information and help.
Example Helper test
Example Helper test
Example Helper test
Example Helper test
Example Helper test
Example Helper test
Testing Controllers
and using testAction()
testAction() examples

Return a rendered view without a layout

testAction() examples

Return a rendered view with a layout

testAction() examples

Return a the result returned from action.

 testAction() examples

Return the viewVars and use fixturized tables

 testAction()

• Simulate a dispatcher call to a url with specific

params.

• Optionally use fixture data.

• Supply an array of url parameters (both GET
and POST possible).
Real World Controller Testing

• Often you can’t use testAction()

• Need to get your hands dirty.
• Real world test time!
 I Mock you!

• Mock objects are fake objects.

• Mocks objects pretend to to be the object they
have mocked.

• Mocks can be actors or critics.

 Critical Mocking

• Critic mock objects provide critical and

introspective methods.

• Critics are generally used to determine if an

inner object has had its methods called.
 Mock Actors

• Mocks in an actor role are used to feed the test

case subject values it may need.

• Often they don’t make expectations. But they

can.
 Making Mocks

• Using Mock::generate()
• You can mock methods that don’t exist.
• This allows you to test methods that haven’t
been written.
 Partial Mocking bird

• In addition to full Mocks you can generate a

partial mock.

• Partial Mocks only have some methods

mocked. The rest are real methods.

• Partial mocks are great for testing classes that

you want partial interaction with.

• Partial mocks can have expectations as well.

 Code coverage

• How much is enough?

• 100% is almost impossible for non-trival
applications.

• Getting close to 100% can require 3x code.

• A healthier goal is 40%-80%.
Code coverage
 What to test?
What you should test What you should test What you most o'en don’t
automatica"y in the browser need to test or can’t

Anything that has a clear CakePHP’s features

“No tasks found “ message
contract (most are well tested, but this doesn’t
in the view
[input->magic->output] mean you shouldn’t test)

Anything that went wrong (In most cases) MVC Whether your site withstands all
already Application flow security attacks.

Anything real money or human If your controller sets the right view
Your interface
lives depend on vars in trivial cases.

Anything you are not confident

CSS and Javascript Your users.
about
 Pointers from Tim & I

• Writing assertions first makes you think about your

interface - and often helps me notice design errors

• However, sometimes I need to hack out a function and

go back and forth between the test and the subject

• use getTests() to limit the tests that run

• Give your tests descriptive names or use custom error

messages
 Pointers from Tim & I

• Play with the testing shell - ultimate

automation is key to world domination!

• Keep tests isolated - two problems need two

tests

• Leave the last test broken when you are done

for the day -> it’s the starting point for
tomorrow
 Pointers from Tim & I

• If you are lost, start from scratch

• Test-driven-development takes getting used to
- don’t force yourself to use it; better to write
tests after code is written than writing no tests

• Do regular breaks
• If testing does not help you start with a
problem, explain that problem to someone else
 Things we skipped

• Testing Behaviors.
• Testing Components.
• Using CakeWebTestCase
 May the green bar
be with you!

Thanks you for coming to CakeFest and

listening to me. Kind regards from Tim!

Thank you to the rest of the core team for

working so hard on CakePHP.
Questions?