Changeset 11922

Timestamp:

10/03/08 09:13:12 (2 months ago)

Author:

fabien

Message:

[doc] [1.1, 1.2] updated information on how to unit test Propel classes

Files:

• doc/branches/1.1/book/15-Unit-and-Functional-Testing.txt (modified) (2 diffs)
• doc/branches/1.2/book/15-Unit-and-Functional-Testing.txt (modified) (2 diffs)

doc/branches/1.1/book/15-Unit-and-Functional-Testing.txt

@@ -314 +314 @@
-    $autoload->addDirectory($sf_symfony_lib_dir.'/util');
-    $autoload->register();
-
->**TIP**
->The generated Propel objects rely on a long cascade of classes, so as soon as you want to test a Propel object, autoloading is necessary. Note that for Propel to work, you also need to include the files under the `plugins/sfPropelPlugin/lib/vendor/propel/` directory and to add the Propel core to the include path (by calling `set_include_path($configuration->getSymfonyLibDir().'/plugins/sfPropelPlugin/lib/vendor'.PATH_SEPARATOR.$configuration->getRootDir().PATH_SEPARATOR.get_include_path()`.
-
-Another good workaround for the autoloading issues is the use of stubs. A stub is an alternative implementation of a class where the real methods are replaced with simple canned data. It mimics the behavior of the real class, but without its cost. A good example of stubs is a database connection or a web service interface. In Listing 15-7, the unit tests for a mapping API rely on a `WebService` class. Instead of calling the real `fetch()` method of the actual web service class, the test uses a stub that returns test data.
@@ -393 +390 @@
-    }
-
+### Unit testing Propel classes
+
+Testing Propel classes is a bit more involving as the generated Propel objects rely on a long cascade of classes. Moreover, you need to provide a valid database connection to Propel and you also need to feed the database with some test data.
+
+Thankfully, it is quite easy as symfony already provides everything you need:
+
+  * To get autoloading, you need to initialize a configuration object
+  * To get a database connection, you need to initialize the `sfDatabaseManager` class
+  * To load some test data, you can use the `sfPropelData` class
+
+A typical Propel test file is shown in Listing 15-9.
+
+Listing 15-9 - Testing Propel classes
+
+    [php]
+    <?php
+
+    include(dirname(__FILE__).'/../bootstrap/unit.php');
+
+    new sfDatabaseManager(ProjectConfiguration::getApplicationConfiguration('frontend', 'test', true));
+    $loader = new sfPropelData();
+    $loader->loadData(sfConfig::get('sf_data_dir').'/fixtures');
+
+    $t = new lime_test(1, new lime_output_color());
+
+    // begin testing your model class
+    $t->diag('->retrieveByUsername()');
+    $user = UserPeer::retrieveByUsername('fabien');
+    $t->is($user->getLastName(), 'Potencier', '->retrieveByUsername() returns the User for the given username');
+
-Functional Tests
-----------------

doc/branches/1.2/book/15-Unit-and-Functional-Testing.txt

@@ -314 +314 @@
-    $autoload->addDirectory($sf_symfony_lib_dir.'/util');
-    $autoload->register();
-
->**TIP**
->The generated Propel objects rely on a long cascade of classes, so as soon as you want to test a Propel object, autoloading is necessary. Note that for Propel to work, you also need to include the files under the `plugins/sfPropelPlugin/lib/vendor/propel/` directory and to add the Propel core to the include path (by calling `set_include_path($configuration->getSymfonyLibDir().'/plugins/sfPropelPlugin/lib/vendor'.PATH_SEPARATOR.$configuration->getRootDir().PATH_SEPARATOR.get_include_path()`.
-
-Another good workaround for the autoloading issues is the use of stubs. A stub is an alternative implementation of a class where the real methods are replaced with simple canned data. It mimics the behavior of the real class, but without its cost. A good example of stubs is a database connection or a web service interface. In Listing 15-7, the unit tests for a mapping API rely on a `WebService` class. Instead of calling the real `fetch()` method of the actual web service class, the test uses a stub that returns test data.
@@ -393 +390 @@
-    }
-
+### Unit testing Propel classes
+
+Testing Propel classes is a bit more involving as the generated Propel objects rely on a long cascade of classes. Moreover, you need to provide a valid database connection to Propel and you also need to feed the database with some test data.
+
+Thankfully, it is quite easy as symfony already provides everything you need:
+
+  * To get autoloading, you need to initialize a configuration object
+  * To get a database connection, you need to initialize the `sfDatabaseManager` class
+  * To load some test data, you can use the `sfPropelData` class
+
+A typical Propel test file is shown in Listing 15-9.
+
+Listing 15-9 - Testing Propel classes
+
+    [php]
+    <?php
+
+    include(dirname(__FILE__).'/../bootstrap/unit.php');
+
+    new sfDatabaseManager(ProjectConfiguration::getApplicationConfiguration('frontend', 'test', true));
+    $loader = new sfPropelData();
+    $loader->loadData(sfConfig::get('sf_data_dir').'/fixtures');
+
+    $t = new lime_test(1, new lime_output_color());
+
+    // begin testing your model class
+    $t->diag('->retrieveByUsername()');
+    $user = UserPeer::retrieveByUsername('fabien');
+    $t->is($user->getLastName(), 'Potencier', '->retrieveByUsername() returns the User for the given username');
+
-Functional Tests
-----------------