Unit testing is a very powerful form of debugging which many developers don’t know about. Once your applications get bigger, it is daunting to make any changes in fear of breaking the entire application. Re-testing the entire application as a whole is both silly and time consuming. Even having to test various components of the application as a user is silly. If all the pieces work, the application will work!

Code should be broken down into small enough chunks (well written OOP) that it can all be executed separately. The idea behind unit testing is programmatically testing all the pieces of your application individually and independently of the next.

We not only want to test how something should work, but also try to break it. If we throw both acceptable and unacceptable values at a function, we can work on handling those error cases, making certain that it will work no matter what is thrown at it, resulting a stricter, clearer application.

In this post we will use SimpleTest, a unit testing framework for PHP.

Don’t worry too much about the following code — I will not go deeply into SimpleTest’s internals as this is more of an introduction than a tutorial. Here is my main test initiation file:

For each file (containing classes) you wish to test, just call $test->addTestFile($file) again and it will be added to the list.

In my example I will deal with testing various array functions, since it’s quite an easy thing to visualize, and may also act as a guide for the actual functions since some may be confusing. Before that, here is a quick explanation about how the testing itself works… You predict what a function will do, and then compare your result with the functions. This sounds a lot more complicated than it is.

There are various different assert functions you can use (plus write your own), but the general idea is the internals of SimpleTest compare the two values, and adds it to the error log if the assertion fails. Aside from basic value comparison, you can also tell it to expect error messages ,exceptions, or the lack thereof. Here is a list of commonly used assertions:

The next parameter of each function is an additional message you can add to the report. Going back to our array example, here is the basic structure for the file we will use:

The only important thing here is we are working with a class, not a function, and that the class has to extend UnitTestCase (or another SimpleTest test unit class). In this example, since we will be worknig with arrays, I set up 4 sample variables we will use, and a function to reset them often so our tests are consistent. For a test function to be ran, the function must start with “test”.

Here we will test the array_push function a few different ways: test that it adds one element, test that the new element is added properly, test that the return value is the new count, and test that passing no arguments will cause an error. We could test it a few other ways as well, but for the sake of example we won’t go into too much detail here.

Our test here accomplishes all of that quite easily, so let’s test the count() function. It should 1) return the right number of elements, 2) generate an error without any parameters, and 3) not generate an error with invalid parameters.

Again, these were quite easy tasks. The only thing new here is testing for errors. SimpleTest will remember all the recent PHP errors, and then when you assertError, it will check for that error message in the queue. Or for no errors (since the last check).

Now, this obviously applies more when using your own functions, and not pre-made ones, so what you have to do is decide exactly how each function should work; which parameters it should expect, what it should return, and what other dependencies (global vars, properties, files, etc.) it requires to run. You can then build your tests to enforce these conditions and keep refactoring your code until they all pass and continue to pass.

Summary: Write code in small, testable units. Test these units separately, and as strictly as possible for incorrect and undocumented behavior. Refactor code as necessary. Writing the tests takes some practice, but it saves a LOT of time in the long run with debugging or making any changes.