Even if this class helped me to solve problems, I’ve never been so proud of it since this class does not behave like a real pager. In fact, I should have named it statementChunker.

In order to paginate through resultsets, the class have to  fetch all resultsets until we reach the desired page, only returning an array of  corresponding resultsets. So this class doesn’t really ‘paginate’, resulting a memory outage when working with large resulsets.

Here is a typical complex query I want to paginate, done the statementPager way :

<?php

$connection = Propel::getConnection();
$query = 'SELECT SUBSTRING_INDEX(field, "/", 1) AS field 
FROM table 
WHERE other_field LIKE '%pattern%' 
GROUP BY field 
ORDER BY sub';
$statement = $connection->prepare($query);
$pager = new statementPager(null, 10);
$pager->setStatement($statement);
$pager->setPage($request->getParameter('page', 1));
$pager->init();
$results = $pager->getResults();

I recently discovered that Propel allows you build custom criterias. I’ve got everything out-of-the-box to run the same query the Propel way, with native SQL pagination :

<?php

$c = new Criteria;
$c->add(TablePeer::FIELD, '%pattern%', Criteria::LIKE);
$c->addAsColumn('field', 'SUBSTRING_INDEX('.TablePeer::FIELD.', "/", 1) AS field');
$c->addDescendingOrderByColumn('sub');
$c->addGroupByColumn('field');

$pager = new sfPropelPager('Table', 20);
$pager->setCriteria($c);
$pager->setPeerMethod('doSelectStmt');
$pager->setPage($request->getParameter('page', 1));
$pager->init();
$results = $pager->getResults()->fetchAll();

That’s a pretty valuable refactoring session : one class less to maintain and a performance boost as an outcome ! (and also a good lesson in humility)

The benefit of this abstraction is that you can reuse the business-logic of pagination and apply it to anything, without reinventing the wheel.

Scott Meves have already submitted a snippet in which he explains how to extend the sfPager class to paginate an array.

Raw SQL

Whatever you use Propel or Doctrine, it is sometimes needed to write raw SQL queries.

$connection = Propel::getConnection();
$query = 'SELECT MAX(%s) AS max FROM %s';
$query = sprintf($query, ArticlePeer::CREATED_AT, ArticlePeer::TABLE_NAME);
$statement = $connection->prepare($query);
$statement->execute();
$resultset = $statement->fetch(PDO::FETCH_OBJ);
$max = $resultset->max;

When you do so, you loose all the relation object mapping. Besides, you cannot use any of the sf*Pager anymore.

Nevertheless, both Propel and Doctrine are based on PDO. It means that using raw queries doesn’t mean bypassing database abstraction. When you execute a query, you still retrieve a collection of PDOResulset objects, which are ‘abstract’ representations of database entries.

the statementPager class

Let’s create a custom pager to paginate this collection (an array of objects) :

class statementPager extends sfPager
{
  protected $resultsetArray = array();

  public function __construct($class = null, $maxPerPage = 10)
  {
    parent::__construct($class, $maxPerPage);
  }

  public function setStatement($statement)
  {
    $this->statement = $statement;
  }

  public function init()
  {
    $this->statement->execute();

    $this->setNbResults($this->statement->rowCount());

    if (($this->getPage() == 0 || $this->getMaxPerPage() == 0))
    {
     $this->setLastPage(0);
    }
    else
    {
     $this->setLastPage(ceil($this->getNbResults() / $this->getMaxPerPage()));
    }
  }

  public function getResults()
  {

    if (($this->getPage() == 0 || $this->getMaxPerPage() == 0))
    {
      $this->setLastPage(0);
    }
    else
    {
      $this->setLastPage(ceil($this->getNbResults() / $this->getMaxPerPage()));
    }

    $row_num = 1;
    while ($resultset = $this->statement->fetch(PDO::FETCH_OBJ))
    {
      if ($row_num > $this->getMaxPerPage()*($this->getPage()-1)
      and $row_num <= ($this->getPage()*$this->getMaxPerPage() ))
      {
        $this->resultsetArray[] = $resultset;
      }
      $row_num++;
    }

    return $this->resultsetArray;
  }

  public function retrieveObject($offset)
  {
    return $this->resultsetArray[$offset];

  }
}

To avoid populating a big array with all resultsets (which is the current limitation of the snippet), we only stack those that match with the current page range ( simulating the limit/offset behavior of a SQL query). This is not an optimal solution, but it really helps keeping memory usage low since the $resultset variable is overwritten on each pass.

To initialize the pager, simply pass a PDOStatement instance to the pager after preparing the query :

$connection = Propel::getConnection(CampainPeer::DATABASE_NAME, Propel::CONNECTION_READ);
$query = 'SELECT COUNT(l.id) AS cnt, column AS custom_column
FROM table c
left join another_table l ON l.id=c.another_id
GROUP BY c.name
order by l.created_at DESC';

$this->statement = $connection->prepare($query);

$this->pager = new statementPager(null, 10);
$this->pager->setStatement($this->statement);
$this->pager->setPage($request->getParameter('page', 1));
$this->pager->init();

The pager is now initialized and can be used just like any pager :

<?php foreach ($pager->getResults() as $resultset): ?>
  <?php print_r($resultset) ?>
<?php endforeach ?>

Will output 10 resultsets :

stdClass Object
(
  [cnt] => 1
  [custom_column] => 526
)
stdClass Object
(
  [cnt] => 3
  [custom_column] => 527
)
stdClass Object
(
  [cnt] => 0
  [custom_column] => 123
)
stdClass Object
(
  [cnt] => 0
  [custom_column] => 187
)
stdClass Object
(
  [cnt] => 1
  [custom_column] => 109
)
stdClass Object
(
  [cnt] => 1
  [custom_column] => 526
)
stdClass Object
(
  [cnt] => 3
  [custom_column] => 527
)
stdClass Object
(
  [cnt] => 3444
  [custom_column] => 456
)
stdClass Object
(
  [cnt] => 110
  [custom_column] => 789
)
stdClass Object
(
  [cnt] => 220
  [custom_column] => 101
)

The main reason that many PHP developers don’t invest earlier into testing solutions is that TDD deals with practice, not knowledge of a particular language or framework.

Learning a test framework and how to write unit and functional tests is quite easy. Build an automated testing solutions is pretty easy too. It just takes some time.

The most difficult part is to learn how to set up good habits in your daily job, which includes :

• Writing relevant tests
• Writing testable code
• Running tests automatically

It’s pretty easy to miss one of these steps during development and fall into the evil counterpart of Test-Driven Development methodology :  Development-Driven Tests, whose workflow can be compared to the old-fashioned and non-agile Waterfall model.

Here are some practices to avoid if you don’t want to fall into DDT :

• Writing tests after the code is finished

If you write the tests after the code, you are likely to treat testing as a constraining process. Your are pretty sure that your class is working, so why should you write test it now right ?

At that point, you will probably want to test only working functionalities, make sure that every test you write passes and that nothing fails at any moment. After all, your code is finished so you don’t want to push it too further and hurt it. That’s Development-Driven Test !

The purpose of TDD is exactly the opposite : Put the code under extreme conditions (edge cases and invalid data) and make sure that failures are handled correctly. Only then should you assert that the class is working under normal conditions.

Tests must be written before any functional code. That forces you to “program to an interface, not an implementation.”

Here’s a useful hint to quickly step into test writing :  Uses the lime::todo() method to write the test-suite roadmap in plain english, and write tests step by step afterward :

$t = new lime_test(3, new lime_output_color());

$t->todo("Test if the class::method() with invalid data throws an exception");
$t->todo("Test the class::method2() with missing parameter uses default values");
$t->todo("Test the class::method3() returns an valid array with valid parameter");

• Updating tests after fixing a bug

When a bug is reported, the first thing to do is to reproduce it in the test environment. Once the bug is clearly identified and reproduced in isolation, the test suite must fail explicitly :

$t->diag('Testing class::method() with new invalid data');
$input_data = "%data";
$t->is(class::method($input_data), true, "'%' should be handled");

Now, you can modify the code in order to make the test suite pass again.

Testing in the real world

To bring TDD in your daily development is definitely not an easy task. Fortunately, the symfony platform provides a complete toolkit to help you dive into testing :

• environments
• bundled test framework (lime)
• tasks and test harnesses for automated test suites

A real world example : an email logger, which I already covered here. We want to test the integration of this functionality throughout the application.

A good practice in OOP is to decouple the logic from the implementation. Both must be isolated : Unit testing (white box) for the implementation, and functional testing (black box) for the logic.

You may wonder, what belongs to unit or functional testing ?

To understand the difference, let’s ask the good questions :

In my code, does the email class generates emails from templates correctly, using my SMTP server with SSL encryption ?

This is pure implementation matters. I have to mock some classes, generate mock email, test config files, and even send it to myself to see if the it works. If I use native sendmail, we must check whether the program is running on the hosting server, that the server is actually reachable etc.

To answer these questions, write Unit Tests.

In my application, does an email is sent to the author when he updates an article ?

Now we talk business logic. Whatever library or server used behind, we just want to make sure that the application fulfills its functional requirements. During this test, we assume that the underlying email mechanism simply works in all cases, with every sending strategy unit-tested in isolation.

To answer this one, which involves more than one step to complete, write a Functional Test.

Implementation example

Suppose that our application registers a ‘mail.log’ listener that will handle the email processing and sending when notified.

The listener for ‘mail.log’ events is registered in the application configuration class. This is where all the email sending implementation is done :

class backendConfiguration extends sfApplicationConfiguration
{
  public function configure()
  {
     $this->dispatcher->connect('mail.log', array($this, 'listenToMailLog'));
  }

  public function listenToMailLog(sfEvent $event)
  {
    if ($this->getEnvironment() == 'prod')
    {
      $connection = new Swift_Connection_SMTP('smtp.domain.com');
      $mailer = new Swift($connection);
      $recipients = new Swift_RecipientList();
      $recipients->addTo($event['to']);
      $message    = new Swift_Message($event['subject'], $event['body'], 'text/html');
      $mailer->send($message, $recipients, $smtp_config['sender']);
    }
  }
}

Note : To go even further, you can imagine some emailLogger classes that implement several strategies of email generation and sending.

Here is the code to use when we want to send an email  :

class articleActions extends sfActions
{
  public function executeUpdate($request)
  {

    // Update code here...

    $this->getContext()->getEventDispatcher()->notify(new sfEvent($this, 'mail.log', array(
      'subject' => '[ARTICLE UPDATE]',
      'body' => 'You have updated the article>',
      'to' => 'me@domain.com'
    )));
  }
}

Testing the event

Let’s create a simple event listener for test purposes. During the test sequence, we want to catch all the notified ‘mail.log’ events, and check if they match some expectations :

include(dirname(__FILE__).'/../../bootstrap/functional.php');

class mockEventListener
{
  public function __construct()
  {
    $this->event = new sfEvent(null, null);
  }

  public function listenToMailLog(sfEvent $event)
  {
    $this->event = $event;
  }

  public function getLastEvent()
  {
    $last_event = $this->event;
    $this->event = new sfEvent(null, null);
    return $last_event;
  }
}

$mockEventListener = new mockEventListener;

$dispatcher = sfContext::getInstance()->getEventDispatcher();
$dispatcher->connect('mail.log', array($mockEventListener, 'listenToMailLog'));

$browser = new sfTestBrowser();

$browser->post('/article/update', array('title' => 'newtitle'))->
  isRequestParameter('module', 'article')->
  isRequestParameter('action', 'update');

$last_event = $mockEventListener->getLastEvent();

$browser->test()->is(
  $last_event->getName(),
  'mail.log',
  'An "email.log" event should have been notified'
);

$browser->test()->is(
  $last_event['subject'],
  '[ARTICLE UPDATE]',
  'The "subject" should be "[ARTICLE UPDATE]"'
);

Let’s run the test now :

$ symfony test:functional backend articleActions

As the number of tests increase, the test suite grows and it becomes a real live documentation about every functional aspects of the application.

]]> http://arpeggios.wordpress.com/2008/11/12/events-functional-testing/feed/ 0 nicolas.martin functional http://arpeggios.wordpress.com/2008/10/10/using-a-module-from-another-project/ http://arpeggios.wordpress.com/2008/10/10/using-a-module-from-another-project/#comments Fri, 10 Oct 2008 13:10:32 +0000 nicolas.martin http://arpeggios.wordpress.com/?p=417 ]]> The MVC paradigm, adopted in symfony from top to bottom, brings highly decoupled components meant to be used independently.

In a symfony application, modules are flexible and allow complex manipulations like :

• forwarding to another module/action and delegate request processing
• rendering a module/action in isolation (like an email generation module)

Unfortunately, this agility is only available inside a project context. You cannot use a module from another project.

Here is a trick to ‘load’ components (modules, libs, validators or whatever) from an external project.

Project configurations and contexts

The Application configuration object is defined early in the process chain. sfContext loads it and creates a sfContext instance for the current application.

Since symfony 1.1, sfContext is not a singleton anymore. It is now possible to have several context instances.

You can create a configuration object for the external project/application, add a sfContext instance to the stack, and switch between them using the sfContext::switchTo() method.

sfContext::createInstance($configuration)
sfContext::switchTo('another_app');

ExternalProjectFilter

Let’s create a filter that will handle all this job early in the process chain.

In /apps/yourapp/config/filters.yml:

rendering: ~
security:  ~

external:
  class: ExternalProjectFilter
  param:
    sf_root_dir: /var/www/external_project_dir
    sf_app: external_app_name
    sf_env: dev
    sf_debug: true

cache:     ~
common:    ~
execution: ~

Now let’s write the ExternalProjectFilter class in /lib/ExternalProjectFilter.class.php

class ExternalProjectFilter extends sfFilter
{
  public function execute($filterChain)
  {
    if ($this->isFirstCall())
    {
      $current_app = sfConfig::get('sf_app');

      $configuration = ProjectConfiguration::getApplicationConfiguration(
        $this->getParameter('sf_app'),
        $this->getParameter('sf_env'),
        $this->getParameter('sf_debug'),
        $this->getParameter('sf_root_dir')
      );

      // Add an instance of the external project on the current context
      sfContext::createInstance($configuration);

      // Add the external project's database connection settings
      Propel::setConfiguration(sfPropelDatabase::getConfiguration());
      Propel::initialize();

      // Autoload external project files
      $autoload = sfSimpleAutoload::getInstance();
      $autoload->addDirectory( $this->getParameter('sf_root_dir').'/lib');
      $autoload->register();

      // Switch back to the current context
      sfContext::switchTo($current_app);
    }

    $filterChain->execute();
  }
}

Example

In /apps/yourapp/modules/article/template/indexSuccess.php

...
sfContext::switchTo('external_app_name');
echo sfContext::getInstance()->getController()->getPresentationFor('customer', 'index');
sfContext::switchTo('your_app_name');
...

Limitations

Projects cannot share the same default database connection name ‘propel’. The trick is to explicitly name the database in your schema/databases.yml :

schema.xml

<?xml version="1.0" encoding="UTF-8"?>
<database name="project" package="lib.model" defaultIdMethod="native" noXsd="true">
  <table name="article">

databases.yml

all:
  project:
    class:          sfPropelDatabase
    param:
      dsn:          mysql://user:pass@host/db
      encoding:     utf8

Since web services are meant to be programatically callable, you cannot use the standard form/post way. One common solution is to to use HTTP authentication.

That said, it could be a good idea to use the same user restriction logic for that method.

About forms

In symfony 1.1 and above, the sfGuard authentification logic has moved to the bundled signin form.

One of the goal of the new form system, which is a full framework by itself, is to enable reuse of components.
It means that the new form object now embeds the request, validation and error handling.

To enable a HTTP authentication form, we simply need to customize the signin form presentation, and enable HTTP as symfony’s request parameters.

Example

This example assumes that you have a symfony application running with sfGuard installed and set up.

The first thing to do is to override the default signin action of the sfGuardAuth module in the application :

~apps/
 |~api/
 | |+config/
 | |+i18n/
 | |+lib/
 | `~modules/
 |   |+rss/
 |   `~sfGuardAuth/
 |     |~actions/
 |     | `-actions.class.php

In the signin methode, we set 401 status code to the response and add the WWW_Authenticate header, to enable HTTP authentification. Then, we simply map HTTP values to the request parameters expected by sfGuard. If user is validated, we redirect the user to the requested page :

class sfGuardAuthActions extends sfActions
{
  public function executeSignin($request)
  {
    $user = $this->getUser();

    if ($user->isAuthenticated())
    {
      return $this->redirect('@homepage');
    }

    $message = 'Authentification required';

    $this->form = new sfGuardFormSignin;

    if (isset($_SERVER['PHP_AUTH_USER']))
    {
      $request->setParameter('signin', array(
        'username' =>$_SERVER['PHP_AUTH_USER'],
        'password' =>$_SERVER['PHP_AUTH_PW'],
      ));

      $this->form->bind($request->getParameter('signin'));
      if ($this->form->isValid())
      {
        $values = $this->form->getValues();
        $this->getUser()->signin($values['user']);

        return $this->redirect($request->getUri());
      }
      else
      {
        $message = $this->form->getErrorSchema();
      }
    }

    $header_message = "Basic realm=\"$message\"";

    $this->getResponse()->setStatusCode(401);
    $this->getResponse()->setHttpHeader('WWW_Authenticate', $header_message);

    return sfView::NONE;
  }
}

You can see that we reuse sfGuard’s error messages in the HTTP header, to get the exact same authentification logic as a normal login form:

The same behavior can be observed using a HTTP request with parameters encoded directly into the URL:

$ curl -v "http://login:pass@apps.localhost/api/api_dev.php/index"
* About to connect() to apps.localhost port 80 (#0)
*   Trying 127.0.0.1... connected
* Connected to apps.localhost (127.0.0.1) port 80 (#0)
* Server auth using Basic with user 'as'
> GET /api/api_dev.php/index HTTP/1.1
> Authorization: Basic YXM6
> User-Agent: curl/7.18.2 (i386-apple-darwin8.11.1) libcurl/7.18.2 zlib/1.2.3
> Host: apps.localhost
> Accept: */*
>
< HTTP/1.1 401 Unauthorized

< Server: Apache/2.0.59 (Unix) PHP/5.2.5 DAV/2
< X-Powered-By: PHP/5.2.5
< Set-Cookie: symfony=2711f6b7440442a3746fc38771072ca7; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
* Authentication problem. Ignoring this.
< Www-Authenticate: Basic realm="password [Required.]
username [The username and/or password is invalid.]"
< Content-Length: 0
< Content-Type: text/html; charset=utf-8
<
* Connection #0 to host apps.localhost left intact
* Closing connection #0

Symfony and propel allows you to easily manage these ‘externals’ connections.

You can create several schema.xml that defines tables for each database.

schema.xml
external_schema.xml

Connection settings for several databases are handled by the databases.yml configuration file :

prod:
  propel:
    class:          sfPropelDatabase
    param:
      dsn:          mysql://user:password@localhost/database
  external:
    class:          sfPropelDatabase
    param:
      dsn:          mysql://login:pass@hostname/external_db_name

Skipping sql code generation

As we only want to access the external database, we can skip the sql generation for the external schema. We only need model objects to read data from that database (and also create, update and delete in case of a full access database).

Propel allows you that by adding the “skipSql” attribute to a table. Refer to the Propel documentation for the complete list of available options.

<table name=“article” idMethod=“native” skipSql=“true”>

By doing such, no sql data will be generated. That way, you can still use propel tasks to automatically load your main database without creating the freshly built tables of the external database, which won’t be used.

Besides, external developers have now a clear view of what database has to be created and used directly, and what database stands has an external reference.

When lauching that task :

$ symfony propel:build-all-load

Only the main schema.xml will build and insert the corresponding sql code in your database.

Using package names

You can also define a name for each propel package that will specify the generated files output destination.

Default is “lib.model”, which referers to the lib/model directory.

Ex:

<database name=“external” package=“lib.model.external”>

Model files will be generated in the lib/model/external sub-folder.

$ symfony propel:build-model

+lib
|+model
|~external
| |+om
| |+map
| |-Account.php
| `-AccountPeer.php
|+om
|+map
|-Article.php
`-ArticlePeer.php

By declaring different package names, propel will build separate .sql files.

$ symfony propel:build-sql

will generate :

lib.model.schema.sql (containing tables defined in schema.xml)
lib.model.external.schema.sql (containing the external database tables)

Using a blank package name

You can also specify a “blank” name for a package. Model files will be generated under the default lib/model directory.

The pattern used for the .sql file generation is <package.name>.schema.sql. Therefore, a schema.sql will be created, even if every table of the schema are ‘sql skipped’.

Here is the default generated code for an update action :

public function executeUpdate($request)
{
  …
  $this->form = new ProductForm(productPeer::retrieveByPk($request->getParameter(‘id‘)));
  $this->form->bind($request->getParameter(‘product‘));
  if ($this->form->isValid())
  {
    …
  }
}

The action automatically binds the product request parameter which correspond to a entire product form.

What if you want to make a simple form for update purpose only ? Like an Ajax simple edit-and-save for one field ?

By default, if you don’t pass all the required fields explicitly, the form will not be valid.

According to the book, you can unset some fields from the from to bypass validation and save:

class ProductForm extends BaseProductForm
{
  public function configure()
  {
    unset($this['created_at']);
  }
}

Let’s create a custom product form for a simple Ajax edit-and-update. As we only want one field to be validate and saved, we have to unset all fields, except the ones we want:

in /lib/form/ProductFormAjax.class.php :

class ProductFormAjax extends BaseProductForm
{
  // Create the form only for these fields
  protected $enabled_fields = array(‘id‘, ‘name‘);
  public function configure()
  {
    foreach($this->getWidgetSchema()->getFields() as $name => $field)
    {
      if (!in_array($name, $this->enabled_fields))
      {
        unset($this[$name]);
      }
    }
  }
}

You now have a simplified update-only form that uses the same field validators defined in your /lib/form/base/BaseProductForm.class.php.

Now, in the actions class, you can choose between the default form and yours depending upon the context :

class ProductActions extends sfActions
{
  public function executeUpdate($request)
  {
    …
    if ($request->isXmlHttpRequest())
    {
      $this->form = new InstallatorFormAjax(
InstallatorPeer::retrieveByPk($request->getParameter(‘id‘)));
    }
    else
    {
      $this->form = new InstallatorForm(
InstallatorPeer::retrieveByPk($request->getParameter(‘id‘)));
    }
    …
  }
  …
  public function executeEditAjax()
  {
    $this->form = new ProductFormAjax(
InstallatorPeer::retrieveByPk($request->getParameter(‘id‘)));
  }
}

• paging
• sorting
• filtering
• any other general job

You end up with actions that implements each functionality, maybe into separate methods :

class articleActions extends sfActions
{
  protected function processSort() { …  }

  protected function processFilter() { …  }

  public function executeIndex()
  {
     $this->processSort();
     $this->processFilter();
     $this->pager = new sfPropelPager(‘Article‘, 20);
     …
  }
} 

Let’s extract these jobs and use them in all your modules.

Extending sfActions

A Symfony action is a stack of extended classes, so you can easily add your own class to the stack and can put all the common code in it.

Let’s factorize all theses functionalities into a custom action class that extends sfActions.

Let’s create the /lib/myBaseActions.class.php file :

class myBaseActions extends sfActions
{
  // Implement your general methods here
  protected function processSort()
  protected function processFilter()
  …
} 

Now, simply change the parent class in your module action class :

class articleActions extends myBaseActions
{
  public function executeIndex()
  {
  }
  …
} 

The dirty job is now centralized and executed implicitly in all your modules.

Besides, extracting the logic that way forces you to write decoupled and cohesive code, as each method only do a specific job.

About auto-generated modules

You should take a look at how a module action generated by the sfAdminGenerator.

• Simply init a module :

$ symfony propel:init-admin article_admin Article

• Go to http://yourapp/article_admin to generate cache files

Check /cache/prod/modules/autoArticle_admin/actions/actions.class.php.

You can get inspired from it, specially from these design principles :

• sorting and filtering infos are stored in the session
• Criteria modifications for both is split into separate methods

From the Symfony book :

Unit tests confirm that a unitary code component provides the correct output for a given input. They validate how functions and methods work in every particular case. Unit tests deal with one case at a time, so for instance a single method may need several unit tests if it works differently in certain situations.

If you write a Symfony plugin that deals with models, say a behavior, you are also invited to write a functional test to make sure that your objects behave correctly.

In that test, you must be able to instantiate one or many objects in a real application context, call methods, save, and check that the final state matches your requirements.

Unit test your plugin

Just like an application unit test, let’s create this file structure:

~plugins/
 `~sfPropelActAsSomethingBehaviorPlugin/
   |+config/
   |+lib/
   |~test/
   | |~bootstrap/
   | | |-fixtures.yml
   | | `-functional.php
   | `~unit/
   |   `-somethingTest.php

Put some sample data in fixtures.yml. Ex:

Article:
  article_1:
    title: my first article
    body: blablabla
    author_id: 1
Author:
  author_1:
    name: nicolas

bootstrap.php will do the following stuff:

• Set up the test database connection
• Delete existing data
• Load fresh new fixtures

$app = ’frontend‘;
require_once dirname(__FILE__).‘/../../../../config/ProjectConfiguration.class.php‘;
$configuration = ProjectConfiguration::getApplicationConfiguration($app, ‘test‘, isset($debug) ? $debug : true);
sfContext::createInstance($configuration);

$fixtures = dirname(__FILE__).‘/fixtures.yml‘;
$databaseManager = new sfDatabaseManager($configuration);
$databaseManager->initialize($configuration);
$con = Propel::getConnection();

ArticlePeer::doDeleteAll();
AuthorPeer::doDeleteAll();

$data = new sfPropelData();
$data->loadData($fixtures, ‘propel‘);

Now, let’s write the test in somethingBehaviorTest.php, using the freshly initialized database with fixtures loaded :

include(dirname(__FILE__).‘/../bootstrap/functional.php‘);
include($configuration->getSymfonyLibDir().‘/vendor/lime/lime.php‘);

$t = new lime_test(23, new lime_output_color());

$c = new Criteria;
$c->add(Author::NAME, ‘nicolas‘);
$author = AuthorPeer::doSelectOne($c);

$t->is($author->countStuff(), 3, "author_1 should have \"3\" stuff");
…

Test !

$ php plugins/sfActAsSomethingPlugin/test/unit/somethingTest.php
1..23
ok 1 - Author_1 should have 3 stuff

Note

foreign references must be respected when deleting data. Then, you must detete them in the correct order (ex: Articles before Authors).

Fixtures must be declared in the correct order as well (ex: Authors before Articles) as they will be inserted sequentially.