README in plugin_test_helper-0.0.2 vs README in plugin_test_helper-0.1.1

- old
+ new

@@ -1,82 +1,75 @@ = plugin_test_helper -plugin_test_helper simplifies plugin testing by creating an isolated Rails ++plugin_test_helper+ simplifies plugin testing by creating an isolated Rails environment that simulates its usage in a real application. == Resources +API + +* http://api.pluginaweek.org/plugin_test_helper + Wiki * http://wiki.pluginaweek.org/Plugin_test_helper Announcement -* http://www.pluginaweek.org/ +* http://www.pluginaweek.org Source * http://svn.pluginaweek.org/trunk/plugins/test/plugin_test_helper Development * http://dev.pluginaweek.org/browser/trunk/plugins/test/plugin_test_helper -== Background +== Descriptiona -As described in http://www.pluginaweek.org/2006/11/24/plugin-tip-of-the-week-testing-your-plugins-the-right-way/, -plugins often need access to a full Rails environment, whether it be accessing a -database, simulating controller access, or something else. Whatever it may be, -you still need to initialize a Rails environment in order to get your tests -working. +Plugins often need to initialize a full Rails environment, whether it be for +accessing a database or simulating controller access. Traditionally, this has +been done by just loading the application that the plugin was added to. +However, this can cause all sorts of environment variables to change, making it +seem as though the plugin is having problems when it may be something else. It +also means that the plugin cannot be tested individually. -Traditionally, this has been done by just loading the application that the -plugin was added to. This has many downfalls, the most important of which is -that loading the application can cause all sorts of things to change, making it -seem as though the plugin is having problems when it may be something else. The -other downfall of this technique is that the plugin cannot be tested individually. -Instead, it must be part of a Rails application. ++plugin_test_helper+ helps solve this problem by allowing plugins to create their +own basic Rails environment with the ability to override any part of it, be it +the database configuration, environment configuration, or adding models, +controllers, helpers, etc. The following testing structure is assumed: -== Solution + your_plugin/ + your_plugin/test + your_plugin/test/app_root + your_plugin/test/app_root/app + your_plugin/test/app_root/config + your_plugin/test/app_root/db + etc. -The solution to this problem is to have the plugin create its own basic Rails -environment with the ability to override any part of it, be it the database -configuration, environment configuration, or adding models, controllers, helpers, -etc. - -plugin_test_helper assumes a testing structure like so: - -your_plugin/ -your_plugin/test -your_plugin/test/app_root -your_plugin/test/app_root/app -your_plugin/test/app_root/config -your_plugin/test/app_root/db -etc. - -The app_root directory is just like your run-of-the-mill Rails application. It +The +app_root+ directory is just like your run-of-the-mill Rails application. It can contain the same directories as your full application. -== How to use plugin_test_helper - -plugin_test_helper creates stubs for testing a plugin, as described in http://www.pluginaweek.org/2006/11/24 - -The following generators are available: +To help generate the various parts of your test application, the following +generators are available: * plugin_test_helper * plugin_test_structure * plugin_test_model * plugin_test_controller * plugin_test_migration -+NOTE+ that you +DO NOT+ need to generate the entire application structure. All +*NOTE* that you <b>DO NOT</b> need to generate the entire application structure. All that is required is that your test helper load plugin_test_helper. If you do not define a part of the test application (such as the environment configurations or the database configuration), then it will use the existing -implementation in plugin_test_helper/generators/plugin_test_structure/templates. -+However+, you can override any of these files by simply defining them in your +implementation in <tt>plugin_test_helper/generators/plugin_test_structure/templates</tt>. +*However*, you can override any of these files by simply defining them in your plugin, using the same directory structure. +== Usage + === plugin_test_helper Generates a test helper file that should be required by all unit/functional/integration tests in your plugin. @@ -92,11 +85,11 @@ 0 tests, 0 assertions, 0 failures, 0 errors === plugin_test_structure Generates the entire test application structure. If you keep all files within -your plugin, then you will not need to depend on the plugin_test_helper plugin +your plugin, then you will not need to depend on the +plugin_test_helper+ plugin when testing it. Example: $ ruby script/generate plugin_test_structure acts_as_most_popular @@ -181,14 +174,29 @@ Finished in 0.000443 seconds. 0 tests, 0 assertions, 0 failures, 0 errors +=== plugin_test_console + +Generates a script for running an interactive console with your plugin's test +application. + +Example: + + $ ruby script/generate plugin_test_console acts_as_most_popular + create vendor/plugins/acts_as_most_popular/test/app_root/../../script + create vendor/plugins/acts_as_most_popular/test/app_root/../../script/console + Loaded suite script/generate + Started + + Finished in 0.000267 seconds. + + 0 tests, 0 assertions, 0 failures, 0 errors + == Dependencies -This plugin does not depend on any other plugins. +This plugin does not depend on the presence of any other plugins. -== Credits +== References -Kudos to Mark Meves over at http://rationalexuberance.org/ for working on the -initial implementation of this plugin. His work has made testing our plugins so -much easier. Thanks Mark! \ No newline at end of file +* {Mark Meves}[http://rationalexuberance.org] for the initial implementation