Unit Testing in CakePHP Part 1 - Introduction to Unit Testing
Posted on 6/5/08 by Tim Koschützki
So you want to read up on Unit Testing in CakePHP? That is great, testing can be such a help in finding bugs. It's a shame that so few clients dedicate a budget to it and then expect their application that contains a ton of complicated code to be stable nevertheless.
Surprisingly, many people do not know yet what unit testing is. In this first part of a whole series you can get a good grasp of what it is and is not.
1.1 Introduction to Unit Testing
According to Wikipedia, unit testing is an automated procedure to ensure your software units work properly. Units are the smallest testable parts of an application. Meaning, they are procedures or functions in procedural programming and object methods in object oriented programming. Classes are also commonly referred to as being the units of the system. Quite a few JUnit (the first testing framework of the XUnit family - made for Java) folks do not like the term "Unit Testing" at all, because they think it is overused. They like to refer to Unit Testing as "Programmer Testing". No, we are not testing programmer here. But programmers are testing their own source code. To me it does not matter. Seriously, I could not care less. No matter what you think a unit is, you will understand what I am talking about here. For the sake of clarity, I will refer to it as "Unit Testing".
The idea behind unit testing is that once you have a unit that you think works, you set up a testcase where you specify some input to the unit and compare the result of your unit with your expected result. You know about the expected result, because you know what your unit is doing (or you should know it). Well, you better know what your unit is supposed to do, or else you should not do programming in the first place... ; ) Then you run the tests and the CakePHP/«insert your framework here» testsuite tells you if they passed or if not, with some graceful message where the error occured.
Now you have that testcase. Now you add testcases for t h a t input and this one. The advantage of this is that once you wrote the tests down they are there (cool, huh?) and you can hold on to them. There is no need anymore for you to open the browser and test everything manually again when you change your system. Instead, you add functionality, run the automated unit tests again, if they pass you are good to go, if they don't pass you broke something. Well, what if you broke something but your tests don't catch it? That's something that UT cannot do for you. You must make sure you have a good test coverage (http://en.wikipedia.org/wiki/Code_coverage) for UT to work very well for you. However, having not enough tests is still much better than having no tests, so....
Typically, the order of the running of the tests should not matter. There might be special cases, but in well over 90% it does not. This should also be your goal, too, to have two different problems if two test cases fail. Keep them all isolated and you will sleep well. For most tests there is also not much configuration to be done. You specify the input, your expected result, crank the handle and evaluate how well you have done. You should typically be able to group tests together, too. When you run these groups you can get a good overview over large components of your system.
If you use a framework - like CakePHP - you should also be able to run all tests to see how well your system works.
Unit Testing also tells you when you are done with your work. If you get a green bar (ie all tests are passing) you are done (except if there are more tests to add, heh). If you get a red bar, you got work to do. Simple.
1.2 So How Does It Work?
Unit Testing generally works with assertions that take two parameters - at least most of them do. The first one is your known expected result and the second one is the output of your unit based on your input. The testsuite then compares the expected result with the output of your unit. The CakePHP Testsuite in its current state strictly relies on http://simpletest.org and thereby inherits SimpleTest's assertions. Let's have a look at them:
| Assertion | What it does | Example |
|---|---|---|
| assertTrue($x) | Fail if $x is false |
$this->assertTrue(1 == true);
|
| assertFalse($x) | Fail if $x is true |
$this->assertFalse(1 === true);
|
| assertNull($x) | Fail if $x is set |
$variable = null;
$this->assertNull($variable); |
| assertNotNull($x) | Fail if $x not set |
$variable = 'something but not null';
$this->assertNotNull($variable); |
| assertIsA($x, $t) | Fail if $x is not the class or type $t |
$tim = new Person;
$this->assertIsA($tim, 'Person'); |
| assertNotA($x, $t) | Fail if $x is of the class or type $t |
$tim = new Person;
$this->assertNotA($tim, 'Animal'); // or maybe I am? o_O |
| assertEqual($x, $y) | Fail if $x == $y is false |
$fahrenheit = 50;
$celsius = (5/9)*($fahrenheit-32); $this->assertEqual(10, $celsius); |
| assertNotEqual($x, $y) | Fail if $x == $y is true |
$this->assertNotEqual('5', 5); // fails, they are equal but not identical
|
| assertWithinMargin($x, $y, $m) | Fail if abs($x - $y) < $m is false |
$this->assertWithinMargin(10, 50, 60); // passes
$this->assertWithinMargin(10, 50, 30); // fails |
| assertOutsideMargin($x, $y, $m) | Fail if abs($x - $y) < $m is true |
$this->assertOutsideMargin(10, 50, 60); // fails
$this->assertOutsideMargin(10, 50, 30); // true |
| assertIdentical($x, $y) | Fail if $x == $y is false or a type mismatch |
$this->assertIdentical(0, false); // will fail since 0 is not false
|
| assertNotIdentical($x, $y) | Fail if $x == $y is true and types match |
$this->assertIdentical(10, 100/10*5 - 40);
|
| assertReference($x, $y) | Fail unless $x and $y are the same variable |
$a = 5;
$b =& $a; $this->assertReference($a, $b); |
| assertClone($x, $y) | Fail unless $x and $y are identical copies, that means they are identical but not referenced |
$a = 5;
$b = 5; $this->assertClone($a, $b); // passes, 5 equals 5, but $a and $b are not references to each other |
| assertPattern($p, $x) | Fail unless the regex $p matches $x |
$this->assertPattern('/hello/i', 'Hello world');
|
| assertNoPattern($p, $x) | Fail if the regex $p matches $x |
$this->assertNoPattern('/heppo/i', 'Hello world'); // passes
|
| expectError($x) | Swallows any upcoming matching error | |
| assert($e) | Fail on failed expectation object $e; use SimpleTest's built in expectation objects to have fun here |
<?php
class TestOfNetworking extends UnitTestCase { ... function assertValidIp($ip, $message = '%s') { $this->assert(new ValidIp(), $ip, $message); // uses validIp expectation } function testGetValidIp() { $server = &new Server(); $this->assertValidIp( $server->getIp(), 'Server IP address->%s'); } } ?> |
Thanks for this introduction.
I'm looking forward for the next part about cake's testsuite.
This blog has been a great resource for me to learn about testing with cakePHP so far.
One little issue: Your example for assertNotNull is the same as for assertNull.