diff options
Diffstat (limited to 'tests/README.md')
| -rw-r--r-- | tests/README.md | 226 |
1 files changed, 0 insertions, 226 deletions
diff --git a/tests/README.md b/tests/README.md deleted file mode 100644 index 365f551a1..000000000 --- a/tests/README.md +++ /dev/null @@ -1,226 +0,0 @@ -# CodeIgniter Unit Tests # - -Status : [](https://travis-ci.org/bcit-ci/CodeIgniter) - -### Introduction: - -This is the preliminary CodeIgniter testing documentation. It -will cover both internal as well as external APIs and the reasoning -behind their implementation, where appropriate. As with all CodeIgniter -documentation, this file should maintain a mostly human readable -format to facilitate clean api design. [see https://arrenbrecht.ch/testing/] - -*First public draft: everything is subject to change* - -### Requirements - -PHP Unit >= 3.5.6 - - pear channel-discover pear.phpunit.de - pear channel-discover pear.symfony.com - pear install phpunit/PHPUnit - -vfsStream - - pear channel-discover pear.bovigo.org - pear install bovigo/vfsStream-beta - -#### Installation of PEAR and PHPUnit on Ubuntu - - Installation on Ubuntu requires a few steps. Depending on your setup you may - need to use 'sudo' to install these. Mileage may vary but these steps are a - good start. - - # Install the PEAR package - sudo apt-get install php-pear - - # Add a few sources to PEAR - pear channel-discover pear.phpunit.de - pear channel-discover pear.symfony-project.com - pear channel-discover components.ez.no - pear channel-discover pear.bovigo.org - - # Finally install PHPUnit and vfsStream (including dependencies) - pear install --alldeps phpunit/PHPUnit - pear install --alldeps bovigo/vfsStream-beta - - # Finally, run 'phpunit' from within the ./tests directory - # and you should be on your way! - -## Test Suites: - -CodeIgniter bootstraps a request very directly, with very flat class -hierarchy. As a result, there is no main CodeIgniter class until the -controller is instantiated. - -This has forced the core classes to be relatively decoupled, which is -a good thing. However, it makes that portion of code relatively hard -to test. - -Right now that means we'll probably have two core test suites, along -with a base for application and package tests. That gives us: - -1. Bootstrap Test - test common.php and sanity check codeigniter.php [in planning] -2. System Test - test core components in relative isolation [in development] -3. Application Test - bootstrapping for application/tests [not started] -4. Package Test - bootstrapping for <package>/tests [not started] - -### Test Environment: - -The test/Bootstrap.php file establishes global constants such as BASEPATH, -APPPATH, and VIEWPATH, initializing them to point to VFS locations. The -test case class employs vfsStream to make a clean virtual filesystem with -the necessary paths for every individual test. - -Within each test case, VFS directory objects are available to use as arguments -to the VFS convenience functions (see below): - -- ci_vfs_root: VFS filesystem root -- ci_app_root: Application directory -- ci_base_root: System directory -- ci_view_root: Views directory - -Classes being instantiated for testing are read from the actual filesystem -by the unit test autoloader, as are mockups created in tests/mocks. If you -need access to the real system directory, the SYSTEM_PATH constant always -points to it. - -Any other resources which need to be read from the path constants must be -created or cloned within your test. Functions for doing so are outlined -below. - -### CI_TestCase Documentation - -Test cases should extend CI_TestCase. This internally extends -PHPUnit\_Framework\_TestCase, so you have access to all of your -usual PHPUnit methods. - -We need to provide a simple way to modify the globals and the -common function output. We also need to be able to mock up -the super object as we please. - -Current API is *not stable*. Names and implementations will change. - - $this->ci_set_config($key, $val) - -Set the global config variables in a mock Config object. If key is an array, -it will replace the entire config array. They are _not_ merged. If called -without any parameters, it will create the mock object but not set any values. -The mock Config object also provides rudimentary item() and load() stubs for -delivering configured values to classes being tested and handling config load -calls, respectively. The load() stub does _not_ actually load any files, it -only records the filename provided. Check the config->loaded array to verify -calls made. - - $this->ci_instance($obj) - -Set the object to use as the "super object", in a lot -of cases this will be a simple stdClass with the attributes -you need it to have. If no parameter, will return the instance. - - $this->ci_instance_var($name, $val) - -Add an attribute to the super object. This is useful if you -set up a simple instance in setUp and then need to add different -class mockups to your super object. - - $this->ci_core_class($name) - -Get the _class name_ of a core class, so that you can instantiate -it. The variable is returned by reference and is tied to the correct -$GLOBALS key. For example: - - $cfg =& $this->ci_core_class('cfg'); // returns 'CI_Config' - $cfg = new $cfg; // instantiates config and overwrites the CFG global - - $this->ci_set_core_class($name, $obj) - -An alternative way to set one of the core globals. - - $this->ci_vfs_mkdir($name, $root) - -Creates a new directory in the test VFS. Pass a directory object to be the -parent directory or none to create a root-level directory. Returns the new -directory object. - - $this->ci_vfs_create($file, $content, $root, $path) - -Creates a new VFS file. '.php' is automatically appended to the filename if -it has no extension. Pass a directory object as the root, and an optional path -to recurse and/or create for containing the file. Path may be a string (such -as 'models/subdir') or an array (e.g. - array('models', 'subdir') ). Existing -directories in the VFS root will be recursed until a new directory is -identified - all others in the path will be created, so you can mix-and-match -old and new directories. If $file is an array (key = name, value = content), -multiple files will be created in the same path. - - $this->ci_vfs_clone($path) - -Clones an existing file from the real filesystem to exist in the same path of -the VFS. Path must be relative to the project root (i.e. - starting with -'system' or 'application'). - - $this->ci_vfs_path($path, $base) - -Creates a VFS file path string suitable for use with PHP file operations. Path -may be absolute from the VFS root, or relative to a base path. It is often -useful to use APPPATH or BASEPATH as the base. - - $this->helper($name) - -Loads a helper from the real filesystem. - - $this->lang($name) - -Loads a language file from the real filesystem and returns the $lang array. - - $this->ci_get_config() __internal__ - -Returns the global config array. Internal as you shouldn't need to -call this (you're setting it, after all). Used internally to make -CI's get_config() work. - - CI_TestCase::instance() __internal__ - -Returns an instance of the current test case. We force phpunit to -run with backup-globals enabled, so this will always be the instance -of the currently running test class. - -### Going forward - -#### 1. Bootstrap Test - -Testing common.php should be pretty simple. Include the file, and test the -functions. May require some tweaking so that we can grab the statics from all -methods (see is_loaded()). Testing the actual CodeIgniter.php file will most -likely be an output test for the default view, with some object checking after -the file runs. Needs consideration. - -#### 2. System Test - -Testing the core system relies on being able to isolate the core components -as much as possible. A few of them access other core classes as globals. These -should be mocked up and easy to manipulate. - -All functions in common.php should be a minimal implementation, or and mapped -to a method in the test's parent class to gives us full control of their output. - -#### 3. Application Test: - -Not sure yet, needs to handle: - -- Libraries -- Helpers -- Models -- MY_* files -- Controllers (uh...?) -- Views? (watir, selenium, cucumber?) -- Database Testing - -#### 4. Package Test: - -I don't have a clue how this will work. - -Needs to be able to handle packages -that are used multiple times within the application (i.e. EE/Pyro modules) -as well as packages that are used by multiple applications (library distributions)
\ No newline at end of file |