Unit Testing

Hooks are used in Drupal to allow modules and themes to listen to or trigger different sorts of events in a Drupal system. During these events Drupal will pause and ask if any modules want to have any say in the event that is currently being triggered.

For example, hooks are commonly used when content is viewed, created, updated, or deleted. So, if we delete a page of content then a delete hook is triggered which allows modules to react to that content item being deleted. Using this, we can react to this and perform clean up operations on items of content that don't exist any more. Our custom module might want to remove items from a database table, or delete associated files since they wont be needed.

This is just one example of how hooks are used in Drupal as they are used in all manner of different situations, and not just listening for content events. Another example of a common Drupal hook is when creating a custom template.

I was talking with a fellow programmer the other day about a poor test that we were reviewing and we got onto the subject of what makes a poor test. The test in question had a reliance on a previous test being run, and the problem we encountered was that on some systems the dependent test was run after this test, which caused it to fail.

This also caused some headaches in local development as it couldn't be run in isolation. We had to ensure that both tests were run, in the correct order.

After fixing the tests so that they could be run independently I created a list of some common problems that programmers might come across when writing tests. These rules can be applied to most coding test, not just unit tests or behavioural tests.

I was looking at some malfunctioning code the other day where the price was pulled out of one API service and sent to another API. The problem stemmed from the fact that the value coming out of the first API was as a string and the second API required the price in pence as an integer.

The difference in formats here meant that the number had to be converted from one format to another. During this process it was found that the value was sometimes out by a single pence.

For example, whilst the first API sent over a value of £20.40, the second API received a value of 2039, which is one penny out. This class did have some unit tests, but the tests but had failed to account for this rounding error.

As it turned out, this wasn't the only problem with the class in question, so I thought I would write up a quick PHP:CSI showing the problems and how I solved them.