Cleaned up and converted readme to markdown format for github

2 files changed, 162 insertions, 137 deletions

diff --git a/tests/README.md b/tests/README.md
new file mode 100644
index 000000000..b53f19506
--- /dev/null
+++ b/tests/README.md
@@ -0,0 +1,162 @@
+# CodeIgniter Unit Tests #
+
+*Do not merge to default until these issues have been addressed*
+
+- Clean up naming conventions
+- Figure out config stuff
+- Figure out database testing
+
+### Introduction:
+
+This is the preliminary CodeIgniter testing documentation. It
+will cover both internal as well as external APIs and the reasoning
+behind their implemenation, where appropriate. As with all CodeIgniter
+documentation, this file should maintain a mostly human readable
+format to facilitate clean api design. [see http://arrenbrecht.ch/testing/]
+
+*First public draft: everything is subject to change*
+
+### Requirements
+
+PHP Unit >= 3.5.6
+
+	pear channel-discover pear.phpunit.de
+	pear install phpunit/PHPUnit
+
+vfsStream
+
+	pear channel-discover pear.php-tools.net
+	pear install pat/vfsStream-alpha
+
+#### 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.symfony-project.com
+
+	# Finally install PHPUnit and vfsStream (including dependencies)
+	pear install --alldeps phpunit/PHPUnit
+	pear install --alldeps pat/vfsStream-alpha
+
+	# 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]
+
+### 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. If key is an array, it will
+replace the entire config array. They are _not_ merged.
+
+    $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_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
diff --git a/tests/readme.txt b/tests/readme.txt
deleted file mode 100644
index 9a299544a..000000000
--- a/tests/readme.txt
+++ /dev/null
@@ -1,137 +0,0 @@
-# Do not merge to default until this is blank #
-
-- Clean up naming conventions
-- Figure out config stuff
-- Figure out database testing
-
-
-
-# -------------- CodeIgniter Testing (4/20/2011) -------------- #
-
-
-# Introduction:
-
-This is the preliminary CodeIgniter testing documentation. It
-will cover both internal as well as external APIs and the reasoning
-behind their implemenation, where appropriate. As with all CodeIgniter
-documentation, this file should maintain a mostly human readable
-format to facilitate clean api design. [see http://arrenbrecht.ch/testing/]
-
-*FIRST PUBLIC DRAFT: EVERYTHING IS SUBJECT TO CHANGE*
-
-# Requirements
-
-1. PHP Unit >= 3.5.6
-    - pear channel-discover pear.phpunit.de
-    - pear install phpunit/PHPUnit
-
-2. vfsStream
-    - pear channel-discover pear.php-tools.net
-    - pear install pat/vfsStream-alpha
-
-
-# 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]
-
-
-## 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.
-
-
-### 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. If key is an array, it will
-	replace the entire config array. They are _not_ merged.
-
-$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_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.
-
-## 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