baking cakes with cakephp

• The dark side of failing tests

  [rant]
  Yesterday, I opened some tickets because some core tests failed while I run them with the new testsuite shell. As I didn’t attach any patches to the tickets I got “attacked” on twitter by some people from the core team, and I even got a nice mail from gwoo (the project manager of CakePHP) that I should stop submitting tickets…
  [/rant]

  Anyway, I think this is a good opportunity to think about failing tests (with tests I primarily mean unit tests).

  Even though “failing tests” may sound quite negative, this is not the case, at least if you practice test driven development (or a similar approach). There, failing tests are an integral part of the process. You start with a failing test, and then you implement the functionality so that the test no longer fails. Or if you make a change, and you break something by accident, then a failing test informs you about it. So, a failing test is quite positive.

  On the other hand, failing tests also have a dark side.

  The longer you wait to fix them, the higher the “costs”. If you fix a failing test immediately, then the costs are almost zero: you know what you changed, and so you can easily fix it. But if you wait a while, then the code is no longer present in your mind and it takes much more effort to fix the failing test. A side effect of this waiting is that it encourages others to do the same. If X doesn’t fix the tests he has broken, why should I care whether my tests run? As another side effect it may undermine the motivation of bug reporters to contribute tests if they see the project members don’t care about tests…

  A special “behavior” of failing tests is that they don’t tell you whether they fail because of an incorrect test case or a bug in the code you test (in practice, this is sometimes obvious, sometimes not, depending on various factors). And they don’t tell you whether they only fail in your environment or everywhere. So, this means, if I run your tests and some of them fail, then all I can say may be: test X fails in my environment (the reason for saying “in my environment” is that I assume you don’t give me broken code, i.e. code with tests you know are failing). As it is an environment-specific issue, I will inform you about it, so it can get fixed. But if you provide broken code, then everyone using it will bother you with the same issue, at least theoretically ;-)

  I think it is obvious what helps to deal with those dark sides: don’t provide code with tests you know are failing, it’s that simple!

  I hope it wasn’t too confusing, and sorry about the rant at the beginning, but sometimes it’s necessary to vent one’s anger ;-)

  ---

  Published on May 09, 2008 | 3 comments
  Tagged with testing

• Writing custom validation rules

  Sometimes the built-in validation rules are not flexible enough for your specific validation needs, and so you have to write your own validation rules. Fortunately, that’s quite easy.

  First, you have to write a method in your model which does the validation. The method must accept at least one parameter (for the value which should be validated). If the data is valid, the method must return true. In the other case it has to return false. Such a method could look like:

  public function validateNotEmpty($value) {
      if (trim($value[key($value)]) == ”) {
          return false;
      } else {
          return true;
      }
  }
  

  One thing you have to notice is that $value is an array containing one key/value pair (in pre-beta releases it has been a single value). The key is the name of the field you validate, and the value contains what the user entered (and hence what you want to validate).

  In the next, and last, step, we have to define that we want to use the method we just wrote to validate a certain field. This is done in the same way as with the built-in validation rules, the only difference is that we have to use the method name as rule name:

  public $validate = array('name' => array('rule' => 'validateNotEmpty'));
  

  You can also write validation rules with additional parameters. Let’s say you want to write a validation rule which validates whether a string contains a certain character. The validation method for this purpose may look like:

  public function validateContainsChar($value, $char) {
      return (strpos($value[key($value)], $char) !== false);
  }
  

  Now, if we want to ensure that the value of the “name” field contains an “x”, then the $validate array is:

  public $validate = array('name' => array('rule' => array('validateContainsChar', 'x')));
  

  That’s it, happy validating!

  ---

  Published on May 04, 2008 | No comments yet
  Tagged with cakephp  model  validation

• Implicit vs. explicit APIs

  When developing an API, one point you have to consider is whether you want to provide an implicit or an explicit API.

  An explicit API is usually quite self-explanatory, the method name tells you what the method does (at least, if it has a good name). Some examples from the core of CakePHP:

  Model::findAll($conditions = null, $fields = null, $order = null, $limit = null, $page = 1, $recursive = null)  // deprecated
  Model::findCount($conditions = null, $recursive = 0)  // deprecated
  FormHelper::checkbox($fieldName, $options = array())
  FormHelper::submit($caption = null, $options = array())
  

  On the other hand, an implicit API doesn’t tell you what the method does (respectively it does it on a more abstract level):

  Model::find($type, $options = array())  // new syntax
  FormHelper::input($fieldName, $options = array())
  

  In the first example, the $type parameter determines what the method does, and in the second example it depends either on the data type of the respective database field or on the value of the “type” option.

  For you as a developer, implementing an implicit API means a) you have to write more code and b) you have to write more documentation (because you also have to explain what the method does)… On the other hand, an implicit API allows you to provide a unified API (e.g. Model::find(’all’), Model::find(’count’), and Model::find(’list’) vs. Model::findAll(), Model::findCount(), and Model::generateList()).

  For a user, an implicit API is probably more difficult to use than an explicit API, at least in the beginning. For example, if you want to get the number of some records, you first look for a method with “count” in its name. With an explicit API you will find the Model::findCount() method, but with an implicit API you probably won’t discover that Model::find() supports a “count” type…

  Anyway, in the end it is up to you to decide which approach better fits to your specific situation. Both approaches have their advantages and disadvantages.

  ---

  Published on May 01, 2008 | 7 comments
  Tagged with design  software engineering

• Making it easier for non-geeks to login with an OpenID

  For geeks it is no big deal to use an URL when they have to login somewhere. But for non-geeks it is probably a bit strange if they have to identify themselves with an URL.

  To make it easier for those users to use an OpenID, JanRain — the company behind the OpenID libraries for different platforms — created a widget called ID Selector, where the users have to choose their OpenID provider and enter the user name part of their OpenID. So they do not have to remember the complete URL. Here a screenshot of how it looks like:

  

  You can see it in action on https://www.idselector.com/user/login.

  The integration of the widget into a login form is easy: insert the provided JavaScript snippet into your code and set the id of the input field for the OpenID to “openid_identifier”. That’s it.

  A “disadvantage” of ID Selector is that there will be ads (even though I haven’t seen any while testing), something you may not want…

  ---

  Published on April 24, 2008 | 3 comments
  Tagged with openid  usability

• Thinking about the model II

  A while ago I wrote an article Thinking about the model in which I shared some ideas about how CakePHP’s Model class could be improved. In this article I want to share another idea for the Model class.

  If you look at the Model class you will see that it represents two different “things”: on the one hand it represents a single record, and on the other hand it represents a table (or to be more generic: a container of records). That’s not that clean from an object-oriented point of view, and hence I think it would make sense to split the Model class into two parts, e.g. Record and Container. All properties and methods related to a single record would be in the Record class, and all table-oriented functionality in the Container class (see also the “Managers” section in the Django book, which describes a very similar concept). In practice it could look like:

  $post = $this->Posts->findById(1); // Posts is a Container which returns a Post object (a Record class)
  $post->delete(); // delete the post with id 1
  

  Maybe this is something for CakePHP 2.0?

  ---

  Published on April 22, 2008 | 23 comments
  Tagged with cakephp  ideas  model

Looking for older articles? Visit the archives!