Eric Schäfer's Blog

Database tests

Eric Schäfer — Mon, 06 Apr 2015 12:03:34 +0000

Database tests are a type of automated tests that do not get enough love these days. Everybody is talking about unit tests, acceptance tests, integration and regression tests.

Database tests have gotten a bad reputation because of supposed unit tests which test functionality through the DB. They pretend to test some kind of model by reading from and writing to the DB. Those are not database tests (and those are not models, by the way). So what is a database test and where does it fit in?

When I have to interact with a database I want to make sure the schema of that DB is formed as expected. The design and implementation of that schema is usually not driven by tests. In test driven design external services like databases are usually mocked, because they are not part of the application. In many organisations the schema might even be designed by a different department and may be subject to regulations. No matter where the design comes from, it might be a good idea to have tests for it.

A database test should be testing if the schema of your database is conforming to your expectations. It can be implemented on two different layers of your database abstraction. Either it uses raw SQL instruction or it uses some kind of data access object of your application. In either case it should only test simple CRUD functionality. The test are supposed to tell us if we can add, read, update and delete rows. If we rely on other database features like auto-increment indexes or triggers then we should also test if those are in place.

Such tests help us determine if somebody changed the schema without updating the code and vice versa. They tell us if Bob ‘optimized’ the database and they tell us if the schema has been adapted to Alices changes in the code. Instead of a large number of tests for business objects breaking, because they were tested through the database we now have tests that pinpoint the source of the problem.

Now that we have our schema tests place, when are they run? If they are reasonably fast and the database is accessible in your development environment then you can run them in your usual TDD/BDD cycle like most of your tests. If they are rather slow or access to the database is non-existent or flaky in your dev system then do not run them in that cycle. You want that cycle to be fast and reliable. Instead you could run them on your CI (continuous integration) server. They can even be run on different deployment stages to identify if database changes have been deployed as well. No more forgetting to apply your schema changes to the production database. For running them selectively you need to make sure they are set up to enable that. E.g. put them in a different folder from our other tests or mark them as DB tests if your testing framework supports that and exclude them where you do not want them to run.

Expecting Exceptions

Eric Schäfer — Sun, 04 May 2014 15:03:20 +0000

Most test tools provide the developer with means to suggest that a test should expect an specific exception. For instance, JUnit the prevalent test tool for the Java language provides an annotation to mark such a test (from the JUnit 4 documentation):

    @Test(expected=IndexOutOfBoundsException.class) 
    public void empty() { 
         new ArrayList<Object>().get(0); 
    }

The annotation marks the method as a test and the parameter “expected” tells JUnit which exception type to expect.

Recently I stumbled about some test code from a co-worker who did the tests for expected exceptions a little different:

    @Test
    public void emptyToo() {
        try {
            new ArrayList<Object>().get(0);
        }
        catch (IndexOutOfBoundsException e) {
            return;
        }
        catch (Exception e) {
            Assert.fail("Wrong Exception raised: " + e);
        }
        Assert.fail("No Exception raised.");
    }

This code does the same as the first one. I asked him why he did it this way instead of the more succinct “canonical” way. I thought maybe he does not know about it. But his answer baffled me.

He argued that tests are living documentation of the usage of the system under test. If somebody would come to this test to see which exceptions it would throw under which circumstances they could use his test code as a template for how to deal with the exceptions. In extreme cases they could even copy the test code verbatim, more or less, if they needed to catch the exceptions at this level.

I have never seen it this way. He is right somehow. There is one thing which bothers me with this solution though. The actual exercise of the system under test is buried deeply inside the try/catch construct. Tests are supposed to be easy to read, but in this case it is not immediately obvious what this test is doing. I would rather have the test tell me right away that it is asserting that an exception is raised when the system under test is exercised with the current setup. The canonical version is explicit about that. Before I even get to read the method name I will know that it is expecting an IndexOutOfBoundsException. The reader of the method will know it and, which is important too, the test framework will know it. The Assert.fail() calls do not really tell the story of the test in a way JUnit can understand. It only sees that some test failure occurred.

Still I like the idea. This might be useful for more complex integration tests...

Separating the Application from the Environment

Eric Schäfer — Sun, 27 Oct 2013 11:38:41 +0000

A useful pattern for developing testable rich client GUI applications is the *[Humble Dialog Box](http://c2.com/cgi/wiki?TheHumbleDialogBox)* by Michael Feathers. I have used variations of it for *[TDD](http://c2.com/cgi/wiki?TestDrivenDevelopment "Test Driven Development")* style development of all kinds of Windows programs. It boils down to have a rather dumb view (the humble dialog box) that delegates the handling of its events to a controller object. The controller does all the magic. It talks to the models and does whatever is necessary to react to the users gestures. When it is done it tells the view how to change its state. The view is mostly passive in this process. It receives events (user gestures), delegates them to the controller and receives updated data. It usually does not contain any logic besides what is needed to retrieve any event related data to hand it over to the controller. The controller talks to the view only through an interface. It does not know the concrete implementation of it.

With this approach it it possible to switch to a different GUI library or support multiple libraries in parallel without changing the controller. Use of this pattern enabled me to drive the design of the controllers and models by tests. It also let me migrate parts of an application from the older .Net Windows-Forms (SWF) to the more modern WPF library without even touching the controllers. All I needed to do was creating new WPF views, which called the same services of the controllers as their old SWF counterparts did. The controller would not know the difference as it did not know the difference between the tests that drove its design and the "real" views. Of course this also lets you use different GUI libraries "in parallel". The controllers and models are implemented once and can be used with different GUI libraries on different platforms.

For Web development I usually follow the *[Ports and Adapters](http://alistair.cockburn.us/Hexagonal+architecture)* pattern by Alistair Cockburn. Instead of having horizontal Layers stacked upon each other, having the user interface on top and the database on the bottom it puts the business layer(s) in the center and services like the UI and the DB on the outside. For each service need of the application there is a port and adapters that plug concrete services into those ports. E.g. there might be a persistence port and an MySQL adapter or an UI port and a Ruby on Rails adapter. A persistence adapter might be a database specific *[Repository](http://martinfowler.com/eaaCatalog/repository.html)* and a UI adapter would be a controller in an MVC framework. There are multiple architectural patterns that are very similar. [The Clean Architecture](http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html) by Robert Martin explains them in more detail.

Lately I was thinking about how I would implement *Ports and Adapters* with regards to rich client GUI applications and how it relates to the *Humble Dialog Box* and then it dawned on me. The *"Controller"* in the *Humble Dialog Box* is actually the application specific business logic, the *Interactor*, the *Control Object*. The views "code behind" is the UI ports adapter for the used GUI library. The term "Controller" was confusing me in this context, because with the usual MVC web frameworks I use the controller only as an adapter to the business logic. It does not contain any business logic itself.

It basically always comes back to separating the application from the environment. The details of the different approaches might differ, but the big picture is always the same.

A Generic WPF-Control

Eric Schäfer — Mon, 21 Nov 2011 20:32:06 +0000

There are several ways to reference generic types from XAML for bindings. Unfortunately there is no way to define a generic type using XAML.

I needed to port a fancy dialog for selecting from a list of items from Winforms to WPF. The original dialog had a generic type parameter for the type of the items. Something along the lines of public class SelectionDialog<TItem> : Form. This is not possible if you want to design the layout of a control with XAML, because the XAML type definition does not allow to define type parameters.

All I did to circumvent this limitation was to create a non generic dialog class which I designed with the Visual Studio XAML designer. Then I created a second class with a type parameter for the items. This class is derived from the XAML designed class and voilà I got a XAML dialog with a type parameter.

Custom Field Handlers for Views 2 (Drupal)

Eric Schäfer — Sun, 09 Jan 2011 15:32:46 +0000

This is a step-by-step example how to create custom field handlers for Views 2 for Drupal. I needed this information myself and all I could find was not going very deep, at least not as deep as I needed it. I learned all the necessary details by reading other handlers that came with the views module (in views/modules) and by extensive use of print_r().

This is the goal: Extending the scheduler module to be able to view a countdown until a node is published or unpublished. Countdown meaning "How many time units until the node is published or unpublished". This would be the perfect job for the views module. Scheduler already exposes its publish_on and unpublish_on fields for use with views.

Defining the supported views version in file scheduler.module:

<?php
function scheduler_views_api() {
  $info['api'] = 2;
  return $info;
}
?>

Defining the table and fields in file scheduler.views.inc:

<?php
function scheduler_views_data() {
  $tables['scheduler']['table']['group'] = t('Scheduler');

  // how is the scheduler table linked to the nodes
  $tables['scheduler']['table']['join']['node'] = array(
    'left_field' => 'nid',
    'field' => 'nid',
  );

  // description of the fields (table columns)
  $tables['scheduler']['publish_on'] = array(
    'title' => t('Publish on'),
    'help' => t('Date/time on which the article will be automatically published'),
    'field' => array(
      'handler' => 'views_handler_field_date',
      'click sortable' => TRUE,
    ),
    'filter' => array(
      'handler' => 'views_handler_filter_date',
      'label' => t('Publish on'),
    ),
    'sort' => array(
      'handler' => 'views_handler_sort_date',
    ),
  );

  $tables['scheduler']['unpublish_on'] = array(
    'title' => t('Unpublish on'),
    'help' => t('Date/time on which the article will be automatically unpublished'),
    'field' => array(
      'handler' => 'views_handler_field_date',
      'click sortable' => TRUE,
    ),
    'filter' => array(
      'handler' => 'views_handler_filter_date',
      'label' => t('Unpublish on'),
    ),
    'sort' => array(
      'handler' => 'views_handler_sort_date',
    ),
  );

  return $tables;
}
?>

I am not going to explain this code in detail because it is really simple and everything is documented really nice in the views help. Since we just exposed existing DB fields we only needed to define how the scheduler table is to be joined with the node table. For displaying the values we could rely on a predefined handler for date values (views_handler_field_date). That is the code that we need to build upon.

What we need now is a custom handler because there is no predefined handler for our purpose. At first we need to define the field. Let's start with a simple second count down:

<?php
  $tables['scheduler']['publish_countdown'] = array(
    'title' => t('Publish countdown'),
    'help' => t('Time until the article will be automatically published'),
    'field' => array(
      'handler' => 'scheduler_handler_field_scheduler_countdown',
      'click sortable' => FALSE,
      'timestamp_field' => 'publish_on',
    ),
  );
?>

Note the handler definition (scheduler_handler_field_scheduler_countdown). Now we need to actually implement the handler. Handlers need to live in their own files. So we create a file scheduler_handler_field_scheduler_countdown.inc:

<?php
class scheduler_handler_field_scheduler_countdown extends views_handler_field {
  function query() {
    $this->ensure_my_table();
    $this->node_table = $this->query->ensure_table('node', $this->relationship);
    $this->field_alias = $this->query->add_field(NULL,
      'IF(publish_on AND publish_on > UNIX_TIMESTAMP(),
        publish_on - UNIX_TIMESTAMP(), NULL)',
      $this->table_alias . '_' . $this->field);
  }
}
?>

This handler class derives from views_handler_field, the base class for field handlers. All we need to do is override the query() method, because the countdown value can be calculated via the query. The add field method of the query adds a new field to the query (dooh!). We need a field in the query result that is calculated like this: publish_on - UNIX_TIMESTAMP(). The rest of the condition statement is to limit the calculation to time stamps that represent future times. This is the actual query that will be performed to determine the fields for a view containing the countdown:

SELECT node.nid AS nid,
       node.title AS node_title,
       IF(publish_on AND publish_on > UNIX_TIMESTAMP(),
           publish_on - UNIX_TIMESTAMP(),
           NULL) AS scheduler_publish_countdown
    FROM node node 
    LEFT JOIN scheduler scheduler ON node.nid = scheduler.nid
    WHERE node.status = 0

We are not done yet. All handlers must be declared in the _views_handlers() hook which can be implemented in the module.views.inc file. So we extend scheduler.views.inc with this function:

<?php
function scheduler_views_handlers() {
  return array(
    'handlers' => array(
      'scheduler_handler_field_scheduler_countdown' => array(
        'parent' => 'views_handler_field',
      )
    )
  );
}
?>

That's all for a simple countdown field. It can be added to views and shows the number of seconds until a node will be published. Our handler only supports a countdown for the publish_on field because that's hard coded into our query. We can provide all the additional parameters we need in the 'field' array:

<?php
  $tables['scheduler']['publish_countdown'] = array(
    'title' => t('Publish countdown'),
    'help' => t('Time until the article will be automatically published'),
    'field' => array(
      'handler' => 'scheduler_handler_field_scheduler_countdown',
      'click sortable' => FALSE,
      'timestamp_field' => 'publish_on',
    ),
  );
?>

Now we can change the handler like this:

<?php
    $time_field = $this->definition['timestamp_field'];
    $this->field_alias = $this->query->add_field(NULL,
      'IF('.$timestamp_field.' AND '.$time_field.' > UNIX_TIMESTAMP(),
        '.$time_field.' - UNIX_TIMESTAMP(), NULL)',
      $this->table_alias . '_' . $this->field);
?>

Since the name of the actual field is now variable we can add a field for a unpublish countdown:

<?php
  $tables['scheduler']['unpublish_countdown'] = array(
    'title' => t('Unpublish second countdown'),
    'help' => t('Time until the article will be automatically unpublished'),
    'field' => array(
      'handler' => 'scheduler_handler_field_scheduler_countdown',
      'click sortable' => FALSE,
      'timestamp_field' => 'unpublish_on',
    ),
  );
?>

If scheduler will support scheduled promotion/demotion of nodes or any other action, we can add countdown fields really easy.

But we still only have second countdowns which are actually not really that useful. We would like to have all kinds of countdowns, like in minutes, hours, days and weeks. But we are not going to create handlers for all those values and a fixed definition of fields for those values is also not so nice. How about making the field definition and the handler more generic regarding the actual display format of the countdowns. That's where field options come in handy.

Until now the custom field handler is pretty simple because it only manipulates the database query to provide derived fields. Now we want to alter the rendering of the fields. The user should be able to select how the countdown should be displayed, e.g. its units of scale. It should also be possible to select how the unit should be displayed. At first we need to define the options form in the options_form() function of the handler. We want the user to able to select seconds, minutes, hours, days or weeks as unit of scale and we also want a smart mode which figures out which unit would be best for the current value of the countdown. For the display of the units the user should be able to select long units (e.g. "4 days" or "6 weeks"), short units (e.g. "4d" or "6w") or no units at all.

<?php
  function options_form(&$form, &$form_state) {
    parent::options_form($form, $form_state);
    $form['countdown_display'] = array(
      '#title' => t('Display countdown as'),
      '#type' => 'radios',
      '#options' => array(
        'smart' => t('Smart mode'),
        'seconds' => t('Seconds'),
        'minutes' => t('Minutes'),
        'hours' => t('Hours'),
        'days' => t('Days'),
        'weeks' => t('Weeks'),
      ),
      '#default_value' => $this->options['countdown_display'],
    );
    $form['units_display'] = array(
      '#title' => t('Display time units'),
      '#type' => 'radios',
      '#options' => array(
        'long' => t('Long (e.g. 3 days)'),
        'short' => t('Short (e.g. 3d)'),
        'none' => t('No units at all'),
    ),
      '#default_value' => $this->options['units_display'],
    );
  }
?>

This code defines two option fields as radio buttons. We need to tell views that there will be two options with default values:

<?php
  function option_definition() {
    $options = parent::option_definition();
    $options['countdown_display'] = array('default' => 'smart');
    $options['units_display'] = array('default' => 'long');
    return $options;
  }
?>

Now the user will be presented this two options, but they will still have no effect. We need to define how the field values will be rendered. A field handler can define a render() function for this task. If there is no such function a value will be displayed as the database query returns it.

Let's define the scale values and the unit names first:

<?php
  const SECOND_SCALE = 1;
  const MINUTE_SCALE = 60;
  const HOUR_SCALE = 3600;
  const DAY_SCALE = 86400;
  const WEEK_SCALE = 604800;

  private $render_params = array(
    'seconds' => array(
      'scale' => self::SECOND_SCALE,
      'singular' => 'second',
      'plural' => 'seconds',
      'abbreviated' => 's',
    ),
    'minutes' => array(
      'scale' => self::MINUTE_SCALE,
      'singular' => 'minute',
      'plural' => 'minutes',
      'abbreviated' => 'min',
    ),
    'hours' => array(
      'scale' => self::HOUR_SCALE,
      'singular' => 'hour',
      'plural' => 'hours',
      'abbreviated' => 'h',
    ),
    'days' => array(
      'scale' => self::DAY_SCALE,
      'singular' => 'day',
      'plural' => 'days',
      'abbreviated' => 'd',
    ),
    'weeks' => array(
      'scale' => self::WEEK_SCALE,
      'singular' => 'week',
      'plural' => 'weeks',
      'abbreviated' => 'w',
    ),
  );
?>

Because we defined the above array of unit properties we do not need a switch-statement for the render function:

<?php
  function render($values) {
    $countdown_display = $this->options['countdown_display'];
    $value = $values->{$this->field_alias};

    # what about the "smart" scale?
    $params = $this->render_params[$countdown_display];

    $scaled_value = round($value / $params['scale']);
    switch ($this->options['units_display']) {
      case 'long':
        $rendered_value = format_plural($scaled_value, '1 '.$params['singular'],
                            '@count '.$params['plural']);
        break;
      case 'short':
        $rendered_value = $scaled_value.$params['abbreviated'];
        break;
      case 'none':
        $rendered_value = $scaled_value;
        break;
    }
    return $rendered_value;
  }
?>

This code does not handle the "smart" scale option yet. We need to examine the actual value and check if it is larger than the scale value of each unit. We want to use the largest unit possible. E.g. if the value is 30 we want seconds as the unit, if the value is 61 we want minutes as the unit (and so on). Just replace the comment in the code above with the code below:

<?php
    if ($countdown_display == 'smart') {
      if ($value > self::WEEK_SCALE) {
        $countdown_display = 'weeks';
      }
      elseif($value > self::DAY_SCALE) {
        $countdown_display = 'days';
      }
      elseif($value > self::HOUR_SCALE) {
        $countdown_display = 'hours';
      }
      elseif($value > self::MINUTE_SCALE) {
        $countdown_display = 'minutes';
      }
      else {
        $countdown_display = 'seconds';
      }
    }
?>

That's it. We are done. The user can now include a countdown until a node is published or unpublished in her views. Actually it should be quite easy to use our handler in other modules for other kinds of countdowns.

The final code can be found here: scheduler.views.inc and scheduler_handler_field_scheduler_countdown.inc

Does TDD lead to inefficient algorithms?

Eric Schäfer — Mon, 02 Nov 2009 19:01:07 +0000

Bob Martin showed in a recent blog post "Echoes from the stone age" how TDDing a sorting algorithm would lead to good ol' bubble sort. That stirred up a heated discussion if TDD is really worth it, if it leads to "inefficient" algorithms.

Nobody ever claimed that TDD is supposed to find algorithms that are optimized. TDD at function level defines the behaviour of functions. The behaviour of a sorting algorithm is that an initially unsorted list is sorted after the algorithm has been applied. Well, that's exactly what bubble sort does.

What are you optimizing for anyway? Speed? Memory consumption? Those are behaviour too (temporal and spatial), but they were not specified in Bobs requirements (a.k.a. tests). If you need a sorting algorithm that sorts a certain number of elements with a certain initial order in a certain time, you can specify that in a test (some testing frameworks support performance test, e.g. AUT). Bubble sort might fail that test. So what? That's the reason why we write tests first. We want to see it fail so we can fix it.

Because we have all the nice tests in place that test the external, non-temporal behaviour we can go and read about sorting algorithms and eventually throw out all that bubble sort code in favour of quick sort. Our tests will find out if we made a mistake. We will know if we break something and our latest test tells us if the chosen algorithm is fast enough for our requirements.

The test might even tell us that bubble sort is good enough. Why waste time on a super efficient algorithm if you need to sort a small number of items that are usually in order, but sometimes a new element is added to the list out of order. Bubble sort does that in one pass. You wont need quick sort, if the average number of items is 10.

Oh, by the way: You don't want to be caught committing premature optimization anyway, do you?

Implicit Type Parameter for Implementing Type

Eric Schäfer — Fri, 24 Apr 2009 08:00:00 +0000

A while ago I had an interesting twitter discussion with Chris Ammerman (@cammerman) about type parameters of generic interfaces (C#). Chris tweeted "I often encounter a situation where I want a generic interface, but the type param should ALWAYS be the type of the implementing class". One example of this is ICloneable. Would it ever be acceptable for ICloneable.Clone() to return an object of a type other than the implementing type of the interface? With ICloneable you will always want to cast the result of Clone() because most of the time you want The Real Thing® instead of System.Object. For that reason many people create their own generic interface:

public interface ICloneable<T> { T Clone(); }
public class Foo : ICloneable<Foo> { Foo Clone() { /* implement me */ } }

This is still ugly. I want this instead:

public interface ICloneable { implementer Clone(); }
public class Foo : ICloneable { Foo Clone() { /* implement me */ } }

implementer would be a keyword like base or this but it would not refer to an object but to a type. It would behave as an implicit type parameter to the interface. This would not only be convenient syntactic sugar. It would also make the use of the parameter explicit. You couldn't do class Foo : ICloneable<Bar> anymore.

List of Tweets: