[buddypress-trac] [BuddyPress] #4889: Move unit test suite into BP core

[buddypress-trac]

#4889: Move unit test suite into BP core
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  boonebgorges
  boonebgorges           |     Status:  new
     Type:  enhancement  |  Milestone:  1.8
 Priority:  high         |    Version:
Component:  Unit Tests   |   Keywords:  has-patch needs-testing dev-
 Severity:  major        |  feedback
-------------------------+-------------------------------------------------
 Thanks to DJPaul's outstanding work, we have a working test suite, which
 currently lives at https://github.com/buddypress/BuddyPress-Unit-Tests.
 Over the last few months, we've written a number of tests covering various
 parts of the codebase, and I'm confident that in the process we've built
 up the suite sufficiently that we can be confident of it (BP is being
 bootstrapped and installed correctly, our helper methods like go_to() are
 working as expected, the data factories are running nicely, etc).

 At this time, I'd like to propose that we move the test suite to
 BuddyPress core. Please see the attached patch.

 Briefly, I've made the following changes:

 - BP tests now use WP's automated test suite as a basis. DJPaul's original
 build was a fork of WP's suite. With my patch, WP's suite is used but is
 untouched.
 - I also abstracted some key parts of the BP setup routine (installation,
 the bootstrap, loading the BP testcase and factories) so that they can
 easily be invoked from other plugins. This makes it possible to daisy-
 chain our unit testing tools from another plugin or a larger project. More
 on this below.

 To test the patch:
 - Apply it to your local trunk checkout
 - Make sure you have the WP tests suite set up on your local installation
 http://make.wordpress.org/core/handbook/automated-testing/
 - (Optional but recommended) Put the following in your ~/.bashrc and then
 source it: `export WP_TESTS_DIR="/home/bgorges/sites/wp-tests"`.
 (Obviously you'll have to replace the path. If you don't do this, you'll
 have to define it inline when you invoke PHPUnit.)
 - cd to your `buddypress` plugin directory
 - Type `phpunit`

 These changes introduce several very significant advantages over the
 current setup.

 1. Ease of use. Because we use the WP test suite out of the box, anyone
 who has the WP test suite set up in their environment can immediately run
 the BP tests by going to the BP plugin directory and typing `phpunit`.

 2. Usable by external BP projects (themes, plugins, entire website
 projects). Say you're building a BuddyPress-dependent plugin, and you want
 to write unit tests. You'll want two things: that BP is up and running
 when your tests run (so you'll have access to BP settings, BP functions,
 BP database tables, etc), and that you have access to BP's testing tools
 (BP_UnitTestCase, BP's data factories). With the current setup, you can
 sorta do this, by using the BP test runner *instead of* the WP test
 runner. But this is somewhat clunky, because (a) it means using the forked
 version of the WP test suite, and (b) if your plugin or project has
 *multiple* dependencies, this won't work - no dependency daisy-chaining.
 My patch changes this. You can declare BP dependency in your own plugin
 tests by including two files: buddypress/tests/includes/loader.php at
 'muplugins_loaded' (this installs and bootstraps BP), and
 buddypress/tests/includes/testcase.php just before you load your own tests
 (this gives you access to BP_UnitTestCase, etc). Here's a real example
 from the BuddyPress Docs tests bootstrap:

 {{{
 // Define the BP_TESTS_DIR for convenience
 if ( ! defined( 'BP_TESTS_DIR' ) ) {
         define( 'BP_TESTS_DIR', dirname( __FILE__ ) .
 '/../../buddypress/tests' );
 }

 // Because we're *dependent* on BP, only load the tests if the core tests
 are available
 // You could modify this to load based on whatever condition you want
 if ( file_exists( BP_TESTS_DIR . '/bootstrap.php' ) ) :

         // Gives access to tests_add_filter()
         require_once getenv( 'WP_TESTS_DIR' ) . '/includes/functions.php';

         // Bootstrap BP and BP Docs at muplugins_loaded
         function _bootstrap_bpdocs() {
                 // Make sure BP is installed and loaded first
                 require BP_TESTS_DIR . '/includes/loader.php';

                 // Then load BP Docs
                 require dirname( __FILE__ ) . '/../loader.php';
         }
         tests_add_filter( 'muplugins_loaded', '_bootstrap_bpdocs' );

         // Bootstrap the core tests
         require getenv( 'WP_TESTS_DIR' ) . '/includes/bootstrap.php';

         // Load the BP test files
         require BP_TESTS_DIR . '/includes/testcase.php';

         // include our custom testcase
         require( dirname(__FILE__) . '/bp-docs-testcase.php' );

 endif;
 }}}

 I'm hopeful that the method that I've set up in the patch will become not
 just the standard for BP plugins, but for any plugin that might need its
 tests to be invoked from another plugin or project.

 3. Better conforms to emerging standards of WP plugin test setup. More and
 more plugins are setting up tests using this exact format, especially now
 that wp-cli (and `wp scaffold plugin-tests`) is becoming more popular.

 4. Higher visibility for the tests. By putting the plugins into BP, we
 ensure that developers checking out trunk will see them, which greatly
 increases the likelihood that they'll *use* them (or even write some of
 their own).

 5. Better integration into core dev workflow. Putting things into Trac
 means that we can have a common revision history, and the core devs can
 reference tests in commit messages, etc.

 Feedback very welcome.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4889>
BuddyPress <http://buddypress.org/>
BuddyPress