Snippet : Propel dans un test unitaire (Symfony 1.0)
Les tests unitaires de base sous symfony 1.0 n’ont rien : pas d’autoload, pas de contexte (à l’inverse des tests fonctionnels).
Ce n’est pas extrêmement gênant, on peux inclure les lib dont on a besoin, mais quand on veux faire des appels à la base de donnée (et donc hydrater des objets, faisant souvent appel à de nombreuses classes liées…) c’est mission impossible.
Voici la solution à base de SimpleAutoload :
define('SF_APP', 'frontend');
define('SF_ENVIRONMENT', 'test');
define('SF_DEBUG', TRUE);
require_once($sf_symfony_lib_dir.'/util/sfCore.class.php');
sfCore::initSimpleAutoload(array(SF_ROOT_DIR.'/lib/model'
,$sf_symfony_lib_dir
,SF_ROOT_DIR.'/lib'
,SF_ROOT_DIR.'/apps/'.SF_APP.'/lib'
,SF_ROOT_DIR.'/plugins'));
set_include_path($sf_symfony_lib_dir . '/vendor' . PATH_SEPARATOR . SF_ROOT_DIR . PATH_SEPARATOR . get_include_path());
sfCore::bootstrap($sf_symfony_lib_dir, $sf_symfony_data_dir);
sfContext::getInstance();
Propel::setConfiguration(sfPropelDatabase::getConfiguration());
Propel::initialize();
Utiliser un environnement « test » permet d’utiliser une base de donnée différente (à configurer dans database.yml).
Ce code pourrait (et c’est préférable) être placé dans un nouveau bootstrap dédiée aux test unitaires avec propel (attention c’est consommateur de ressource quand même, donc à n’utiliser que par obligation – à moins d’être heureux d’attendre 10s avant chaque test). Tout de suite après vous pouvez tout faire comme dans une action symfony de base, vous avez accès à toutes vos classes.