I like test driven development. I don’t like adding required files to test script manually because it’s tedious and I am lazy. I really like Symfony’s autoloading feature. Unfortunately, this feature is not available for running unit tests. Running symfony test-unit without including any of the required files, tests will not run.

Fortunately, there is an elegant solution. The idea is based on the Symfony CLI environment. At the top of the test script, add the following lines (or put them in a file and include that file):

<?php
require_once ‘PHPUnit/Framework.php’;

define(’SF_ROOT_DIR’,      realpath(dirname(__file__).’/../..’));
define(’SF_APP’,           ‘frontend’);
define(’SF_ENVIRONMENT’,   ‘cli’);
define(’SF_DEBUG’,          false);

require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.’apps’.
DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.’config’.
DIRECTORY_SEPARATOR.’config.php’);
?>

These lines should be familiar if you have worked with Symfony CLI. Basically, they are boilerplate code for any Symfony CLI app. With any luck, Symfony should load classes for you automagically.

As a software developer, I always find it challenging to account for non-functional requirements while developing software. All software clients and project managers will tell us they want their software to be efficient, effective, fast, secure, scalable, maintainable (not restricted to codes), usable, and resilient. A lot of times (though not always), these constraints are vague, unquantifiable, and contradictory (for example, the most effective way of doing things may not necessarily be the fastest).

It is not uncommon for software developers (myself included), who have been programmed to think and work with logical, tangible, and quantifiable entities, to sweep these constraints under the rug until, one day they come back to haunt us. Yet I religiously believe these constraints, to some extent, can be implemented in the software. A lot of them can be accounted for during the design phase of development.

For example, we are 2 weeks into the Gamboozle Fantasy Sports project, and here are 3 non-functional constraints that stood out during the design phase.

1.      Potential Performance Deterioration As A result Of Data Growth. The way we decided to deal with this constraint was to implement an archive module, which is scheduled to migrate old data from some of the “bigger” tables to new tables. Ideally, a simple SQL INSERT.. SELECT statement will do the job. Since this archived data will still be accessed, we need a mechanism to identify which tables (current vs. archive, and if archive, which archive) the end-users are trying to access. A naming convention for these archive tables is needed too.

2.      Efficient Computation. As part of the business requirement, a number of aggregate values have to be displayed regularly to the end-users. Instead of computing these values on-the-fly, we decided to devise a calculate-once-display-often mechanism to help lighten the frequency of number crunching.

3.      Code Maintainability. Since this project involves PHP and JAVA components sharing the same database, there will definitely be some redundant code in the object-relation mapping (ORM) layer. We have decided to use Propel and Torque as the PHP and JAVA ORM layers respectively. Since Propel is ported from Torque, their XML database schema files are very similar. So we will be able to generate 1 common XML database schema file for both components. In this way, any modification to the database schema, for example, adding new columns, dropping existing columns, type change etc., can be easily propagated to both the PHP and JAVA ORM classes.