Upgrade to KH 3.1.3.1

This commit is contained in:
Deon George
2011-05-13 16:00:25 +10:00
parent 8013aadc4c
commit 6d256839fc
675 changed files with 22771 additions and 24111 deletions

View File

@@ -1,5 +0,0 @@
1. **UnitTest**
- [Testing](unittest.testing)
- [Mock Objects](unittest.mockobjects)
- [Troubleshooting](unittest.troubleshooting)
- [Testing workflows](unittest.testing_workflows)

View File

@@ -0,0 +1,2 @@
# Unittest

View File

@@ -0,0 +1,5 @@
## [UnitTest]()
- [Testing](testing)
- [Mock Objects](mockobjects)
- [Troubleshooting](troubleshooting)
- [Testing workflows](testing_workflows)

View File

@@ -12,7 +12,7 @@ Just navigate to http://example.com/unittest. You may need to use http://example
If you're writing a test for your application, place it in "application/tests". Similarly, if you're writing a test for a module place it in modules/[modulefolder]/tests
Rather than tell you how to write tests I'll point you in the direction of the [PHPUnit Manual](http://www.phpunit.de/manual/3.4/en/index.html). One thing you should bear in mind when writing tests is that testcases should extend Kohana_Unittest_Testcase rathr than PHPUnit_Framework_TestCase.
Rather than tell you how to write tests I'll point you in the direction of the [PHPUnit Manual](http://www.phpunit.de/manual/3.4/en/index.html). One thing you should bear in mind when writing tests is that testcases should extend Unittest_Testcase rather than PHPUnit_Framework_TestCase, doing so gives you access to useful kohana specific helpers such as `setEnvironment()`.
Here's a taster of some of the cool things you can do with phpunit:
@@ -24,7 +24,7 @@ Ordinarily you could use a foreach loop to iterate over an array of test data, h
<?php
Class ReallyCoolTest extends Kohana_Unittest_TestCase
Class ReallyCoolTest extends Unittest_TestCase
{
function providerStrLen()
{
@@ -67,7 +67,7 @@ To allow users to selectively run tests you need to organise your tests into gro
* @group somegroup
* @group somegroup.morespecific
*/
Class AnotherReallyCoolTest extends Kohana_Unittest_TestCase
Class AnotherReallyCoolTest extends Unittest_TestCase
{
/**
* Tests can also be grouped too!

View File

@@ -4,7 +4,7 @@ Having unittests for your application is a nice idea, but unless you actually us
## Testing through the webui
The web ui is a fairly temporary solution, aimed at helping developers get into unittesting and code coverage. Eventually it's hoped that people migrate on to CI servers, but it's fine for calculating code coverage locally.
The web ui is a fairly temporary solution, aimed at helping developers get into unittesting and code coverage. Eventually it's hoped that people migrate on to the termainl & CI servers.
To access it goto
@@ -34,15 +34,15 @@ You can also specify a custom test suite loader (enter the path to your tests.ph
## Looping shell
I personally prefer to do all of my development in an advanced text editor such as vim/gedit/np++.
If you're developing in a text editor such as textmate, vim, gedit etc. chances are phpunit support isn't natively supported by your editor.
To test while I work I run tests in an infinte looping. It's very easy to setup and only takes a few commands to setup.
On nix you can run the following commands in the terminal:
In such situations you can run a simple bash script to loop over the tests every X seconds, here's an example script:
while(true) do clear; phpunit; sleep 8; done;
In my experience this gives you just enough time to see what's going wrong before the tests are rerun.
It's also quite handy to store common phpunit settings (like path to the bootstrap) in a a phpunit xml file to reduce the amount that has to be written in order to start a loop.
You will probably need to adjust the timeout (`sleep 8`) to suit your own workflow, but 8 seconds seems to be about enough time to see what's erroring before the tests are re-run.
In the above example we're using a phpunit.xml config file to specify all the unit testing settings & to reduce the complexity of the looping script.
## Continuous Integration (CI)