Development Unit Tests

When I release the new library I’m also hoping to release all the tests for the library classes.

I had written quite a few tests for the library before the re-structure but I didn’t have anywhere near as much coverage as I would have liked. I’ve since made it a point to write tests for each libary class as I move them over to the new system.

So far this has been a very useful exercise, particularly with my form classes. I’d always planned on making a few minor changes to the form classes and form builder but not quite as many as I have. The changes came about because as I was writing my tests for the new functionality, adding decorators, I noticed a line of code that wasn’t really necessary, with my tests it was trivial to decide on a new api for the classes and then modify my code to ensure everything worked, after a couple of minor tweaks to the code it was so reassuring to see that the 18 tests for my text input class still worked.

Why am I writing this? Well the main reason it that I believe four years ago when I started writing tests I didn’t realise the main benefit. Back then I mistakenly thought that the main benefit of tests was to ensure that the code worked as intended as is and after any changes. Now, to me the main benefit of tests is in creating the best api for your classes.

Not rocket science I know but sometimes, like OOP you have to make the connection yourself.

Planned minor changes – Form Objects and Form Builder

Whilst I am working on the big development in the post below I am also going to make a few minor changes to some of the other classes in my library.

First are the form builders and the form input classes, as it stands at the moment the form input classes create the html for the input and the form builder adds the html, div tags around the individual elements.

I’m happy with the system as it stands but figured that it may be wise to offer a few extra options. To start with I have moved responsibility for the html (divs) from the form builder and into individual decorator classes.  The form builder will now call a decorator and use that to add structure to the form, there are currently three decorators, div, p and tr.

I have also modified the XML file structure, the layout (div styling) no longer resides in the core XML file, just structure and validation, layout will reside in separate files.

The reason for this is two fold, first, on a good percentage of the forms I created with the builder, the same layout stying was used for each row. Second, you rarely define a class, style and id so it seemed sill to have all the extra nodes in the xml file.

When using the decorators you will now only need to define what you want to change, not every node, even if empty. You will also be able to define a ‘default’  layout to use if none has been defined for each element.

Below is an example of how to use the decorator and form objects on their own, without the form builder.

$input = new core_form_inputs_text('text_input');
$input->add_attributes(array('label'=>'Text Input',
                             'size'=>25,
                             'maxlength'=>255,
                             'class'=>NULL,
                             'style'=>NULL,
                             'value'=>NULL));

$decorator = new core_form_decorators_div($input);
$decorator->add_attributes(array('container'=>array('style'=>'color: red;'),
                                 'label'=>array('style'=>'font-weight: bold;'),
                                 'element'=>array('class'=>'newclass',
                                                  'id'=>'new_id')));

echo $decorator->get_html();

As well as the changes listed above I have also made a few changes to the form objects themselves, below is an overview of the text input class and the base class. I will explain the changes when I have completed a few of the other form objects and ensured that all my tests work.

Form text input class overview