Merge branch 'master' of github.com:Codeception/codeception.github.com

Davert · Davert · commit 7f2157e518ba · 2013-01-16T01:05:31.000+02:00
diff --git a/docs/01-Introduction.markdown b/docs/01-Introduction.markdown
@@ -138,4 +138,7 @@ $I->seeInDatabase('users', array('id' => 1, 'username' => 'miles'));
 
 Despite the wide popularity of TDD, few PHP developers ever write automatic tests for their applications. The Codeception framework was developed to make the testing actually fun. It allows writing unit, functional, integration, and acceptance tests in one style.
 
-It could be called a BDD framework. All Codeception tests are written in a descriptive manner. Just by looking in the test body you can get a clear understanding of what is being tested and how it is performed. Even complex tests with many assertions are written in a simple PHP DSL.
+It could be called a BDD framework. All Codeception tests are written in a descriptive manner. Just by looking in the test body you can get a clear understanding of what is being tested and how it is performed. Even complex tests with many assertions are written in a simple PHP DSL.
+
+
+* Next Chapter: [GettingStarted](/docs/02-GettingStarted)
diff --git a/docs/01-Introduction.md b/docs/01-Introduction.md
@@ -0,0 +1,2 @@
+
+Next Chapter: [GettingStarted](/docs/02-GettingStarted)
diff --git a/docs/02-GettingStarted.markdown b/docs/02-GettingStarted.markdown
@@ -321,4 +321,8 @@ There are plenty of useful Codeception commands.
 
 ## Conclusion
 
-We took a look into the Codeception structure. Most of the things you need were already generated by the `bootstrap` command. After you have reviewed the basic concepts and configurations, you can start writing your first scenarios. 
+We took a look into the Codeception structure. Most of the things you need were already generated by the `bootstrap` command. After you have reviewed the basic concepts and configurations, you can start writing your first scenarios. 
+
+
+* Previous Chapter: [Introduction](/docs/01-Introduction)
+* Next Chapter: [Modules](/docs/03-Modules)
diff --git a/docs/02-GettingStarted.md b/docs/02-GettingStarted.md
@@ -0,0 +1,3 @@
+
+Previous Chapter: [Introduction](/docs/01-Introduction)
+Next Chapter: [Modules](/docs/03-Modules)
diff --git a/docs/03-Modules.markdown b/docs/03-Modules.markdown
@@ -369,3 +369,8 @@ Codeception provides modules to emulate web requests, access data, interact with
 For your application you might need custom actions. These can be defined in helper classes.
 If you have written a module that may be useful to others, share it.
 Fork the Codeception repository, put the module into the `src/Codeception/Module` directory, and send a pull request. Many thanks if you do so.
+
+
+
+* Previous Chapter: [GettingStarted](/docs/02-GettingStarted)
+* Next Chapter: [AcceptanceTests](/docs/04-AcceptanceTests)
diff --git a/docs/03-Modules.md b/docs/03-Modules.md
@@ -0,0 +1,3 @@
+
+Previous Chapter: [GettingStarted](/docs/02-GettingStarted)
+Next Chapter: [AcceptanceTests](/docs/04-AcceptanceTests)
diff --git a/docs/04-AcceptanceTests.markdown b/docs/04-AcceptanceTests.markdown
@@ -392,3 +392,8 @@ And in the end we performed assertion on current content.
 ## Conclusion
 
 Writing acceptance tests with Codeception and PhpBrowser is a good start. You can easily test your Joomla, Drupal, Wordpress sites, as well as those made with frameworks. Writing acceptance tests is like describing a tester's actions in PHP. They are quite readable and very easy to write. Don't forget to repopulate the database on each test run.
+
+
+
+* Previous Chapter: [Modules](/docs/03-Modules)
+* Next Chapter: [FunctionalTests](/docs/05-FunctionalTests)
diff --git a/docs/04-AcceptanceTests.md b/docs/04-AcceptanceTests.md
@@ -0,0 +1,3 @@
+
+Previous Chapter: [Modules](/docs/03-Modules)
+Next Chapter: [FunctionalTests](/docs/05-FunctionalTests)
diff --git a/docs/05-FunctionalTests.markdown b/docs/05-FunctionalTests.markdown
@@ -166,4 +166,8 @@ But you can demonstrate a sample application with your framework which uses Code
 
 Functional tests are great if you are using powerful frameworks. By using functional tests you can access and manipulate their internal state. 
 This makes your tests shorter and faster. In other cases, if you don't use frameworks, there is no practical reason to write functional tests.
-If you are using a framework other than the ones listed here, create a module for it and share it with community.
+If you are using a framework other than the ones listed here, create a module for it and share it with community.
+
+
+* Previous Chapter: [AcceptanceTests](/docs/04-AcceptanceTests)
+* Next Chapter: [UnitTests-TEST](/docs/06-UnitTests-TEST)
diff --git a/docs/05-FunctionalTests.md b/docs/05-FunctionalTests.md
@@ -0,0 +1,3 @@
+
+Previous Chapter: [AcceptanceTests](/docs/04-AcceptanceTests)
+Next Chapter: [UnitTests-TEST](/docs/06-UnitTests-TEST)
diff --git a/docs/06-UnitTests-TEST.markdown b/docs/06-UnitTests-TEST.markdown
@@ -209,4 +209,8 @@ PHPUnit tests are very cool, but for complex tests you want to have more strict
 
 ## Conclusion
 
-PHPUnit tests is a first-class citizen in test suites. Whenever you need to write and execute unit tests, you don't need to install PHPUnit manually, but use a Codeception to execute them. Some nice features are added to common unit tests by integrating Codeception modules. For most of unit and integration testing PHPUnit tests are just enough. They are fast and easy to maintain. But when you need some advanced features like mocking, use the special Cest format, described in next chapters.
+PHPUnit tests is a first-class citizen in test suites. Whenever you need to write and execute unit tests, you don't need to install PHPUnit manually, but use a Codeception to execute them. Some nice features are added to common unit tests by integrating Codeception modules. For most of unit and integration testing PHPUnit tests are just enough. They are fast and easy to maintain. But when you need some advanced features like mocking, use the special Cest format, described in next chapters.
+
+
+* Previous Chapter: [FunctionalTests](/docs/05-FunctionalTests)
+* Next Chapter: [UnitTestsScenarios](/docs/07-UnitTestsScenarios)
diff --git a/docs/06-UnitTests-TEST.md b/docs/06-UnitTests-TEST.md
@@ -0,0 +1,3 @@
+
+Previous Chapter: [FunctionalTests](/docs/05-FunctionalTests)
+Next Chapter: [UnitTestsScenarios](/docs/07-UnitTestsScenarios)
diff --git a/docs/07-UnitTestsScenarios.markdown b/docs/07-UnitTestsScenarios.markdown
@@ -205,4 +205,8 @@ That's because you can't test the method `render` invoked once and not invoked i
 ## Conclusion
 
 You are free to decide the testing framework you will use for unit tests. Codeception and PHPUnit run the same engine.
-Codeception provides you with a cool DSL to simplify your unit tests. You are writing the scenario definitions, not the actual executed code. Behind the scenes all the dirty work is done by Codeception. You write only the testing logic.
+Codeception provides you with a cool DSL to simplify your unit tests. You are writing the scenario definitions, not the actual executed code. Behind the scenes all the dirty work is done by Codeception. You write only the testing logic.
+
+
+* Previous Chapter: [UnitTests-TEST](/docs/06-UnitTests-TEST)
+* Next Chapter: [UnitTests-CEST](/docs/08-UnitTests-CEST)
diff --git a/docs/07-UnitTestsScenarios.md b/docs/07-UnitTestsScenarios.md
@@ -0,0 +1,3 @@
+
+Previous Chapter: [UnitTests-TEST](/docs/06-UnitTests-TEST)
+Next Chapter: [UnitTests-CEST](/docs/08-UnitTests-CEST)
diff --git a/docs/08-UnitTests-CEST.markdown b/docs/08-UnitTests-CEST.markdown
@@ -322,4 +322,8 @@ If you don't use ORMs and MySQL, consider using SQLite for testing instead.
 
 ## Conclusion
 
-Codeception has it's powers and it's limits. We believe Codeception's limitations keep your tests clean and narrative. Codeception makes writing bad code for tests more difficult. Codeception has simple but powerful tools to create stubs and mocks. Different modules can be attached to unit tests which, just for an example, will simplify database interactions. 
+Codeception has it's powers and it's limits. We believe Codeception's limitations keep your tests clean and narrative. Codeception makes writing bad code for tests more difficult. Codeception has simple but powerful tools to create stubs and mocks. Different modules can be attached to unit tests which, just for an example, will simplify database interactions. 
+
+
+* Previous Chapter: [UnitTestsScenarios](/docs/07-UnitTestsScenarios)
+* Next Chapter: [Data](/docs/09-Data)
diff --git a/docs/08-UnitTests-CEST.md b/docs/08-UnitTests-CEST.md
@@ -0,0 +1,3 @@
+
+Previous Chapter: [UnitTestsScenarios](/docs/07-UnitTestsScenarios)
+Next Chapter: [Data](/docs/09-Data)
diff --git a/docs/09-Data.markdown b/docs/09-Data.markdown
@@ -245,3 +245,8 @@ Using fixtures simplifies your testing code. Name your fixtures wisely and your
 
 Codeception is not abandoning the developer when dealing with data. Tools for database population and cleanups are bundled within the Db module.
 To manipulate sample data in a test, use fixtures that can be defined within the bootstrap file.
+
+
+
+* Previous Chapter: [UnitTests-CEST](/docs/08-UnitTests-CEST)
+* Next Chapter: [WebServices](/docs/10-WebServices)
diff --git a/docs/09-Data.md b/docs/09-Data.md
@@ -0,0 +1,3 @@
+
+Previous Chapter: [UnitTests-CEST](/docs/08-UnitTests-CEST)
+Next Chapter: [WebServices](/docs/10-WebServices)
diff --git a/docs/10-WebServices.markdown b/docs/10-WebServices.markdown
@@ -204,4 +204,8 @@ class ApiHelper extends \Codeception\Module {
 
 ## Conclusion
 
-Codeception has two modules that will help you to test various web services. They need a new `api` suite to be created. Remember, you are not limited to test only response body. By including Db module you may check if a user was created after the `CreateUser` call. You can improve testing scenarios by using REST or SOAP responses in your helper methods.
+Codeception has two modules that will help you to test various web services. They need a new `api` suite to be created. Remember, you are not limited to test only response body. By including Db module you may check if a user was created after the `CreateUser` call. You can improve testing scenarios by using REST or SOAP responses in your helper methods.
+
+
+* Previous Chapter: [Data](/docs/09-Data)
+* Next Chapter: [Codecoverage](/docs/11-Codecoverage)
diff --git a/docs/10-WebServices.md b/docs/10-WebServices.md
@@ -0,0 +1,3 @@
+
+Previous Chapter: [Data](/docs/09-Data)
+Next Chapter: [Codecoverage](/docs/11-Codecoverage)
diff --git a/docs/11-Codecoverage.markdown b/docs/11-Codecoverage.markdown
@@ -134,3 +134,7 @@ It's never been easier to setup local and remote code coverage. Just one config
 you the most complete information on which parts of your applications are tested and which are not.
 
 
+
+
+
+* Previous Chapter: [WebServices](/docs/10-WebServices)
diff --git a/docs/11-Codecoverage.md b/docs/11-Codecoverage.md
@@ -0,0 +1,2 @@
+
+Previous Chapter: [WebServices](/docs/10-WebServices)
diff --git a/docs/AcceptanceTests b/docs/AcceptanceTests
@@ -0,0 +1,3 @@
+
+Previous Chapter: [Modules](/docs/03-Modules)
+Next Chapter: [FunctionalTests](/docs/05-FunctionalTests)
diff --git a/docs/Codecoverage b/docs/Codecoverage
@@ -0,0 +1,2 @@
+
+Previous Chapter: [WebServices](/docs/10-WebServices)
diff --git a/docs/Data b/docs/Data
@@ -0,0 +1,3 @@
+
+Previous Chapter: [UnitTests-CEST](/docs/08-UnitTests-CEST)
+Next Chapter: [WebServices](/docs/10-WebServices)
diff --git a/docs/FunctionalTests b/docs/FunctionalTests
@@ -0,0 +1,3 @@
+
+Previous Chapter: [AcceptanceTests](/docs/04-AcceptanceTests)
+Next Chapter: [UnitTests-TEST](/docs/06-UnitTests-TEST)
diff --git a/docs/GettingStarted b/docs/GettingStarted
@@ -0,0 +1,3 @@
+
+Previous Chapter: [Introduction](/docs/01-Introduction)
+Next Chapter: [Modules](/docs/03-Modules)
diff --git a/docs/Introduction b/docs/Introduction
@@ -0,0 +1,2 @@
+
+Next Chapter: [GettingStarted](/docs/02-GettingStarted)
diff --git a/docs/Modules b/docs/Modules
@@ -0,0 +1,3 @@
+
+Previous Chapter: [GettingStarted](/docs/02-GettingStarted)
+Next Chapter: [AcceptanceTests](/docs/04-AcceptanceTests)
diff --git a/docs/UnitTests-CEST b/docs/UnitTests-CEST
@@ -0,0 +1,3 @@
+
+Previous Chapter: [UnitTestsScenarios](/docs/07-UnitTestsScenarios)
+Next Chapter: [Data](/docs/09-Data)
diff --git a/docs/UnitTests-TEST b/docs/UnitTests-TEST
@@ -0,0 +1,3 @@
+
+Previous Chapter: [FunctionalTests](/docs/05-FunctionalTests)
+Next Chapter: [UnitTestsScenarios](/docs/07-UnitTestsScenarios)
diff --git a/docs/UnitTestsScenarios b/docs/UnitTestsScenarios
@@ -0,0 +1,3 @@
+
+Previous Chapter: [UnitTests-TEST](/docs/06-UnitTests-TEST)
+Next Chapter: [UnitTests-CEST](/docs/08-UnitTests-CEST)
diff --git a/docs/WebServices b/docs/WebServices
@@ -0,0 +1,3 @@
+
+Previous Chapter: [Data](/docs/09-Data)
+Next Chapter: [Codecoverage](/docs/11-Codecoverage)
diff --git a/docs/modules/AMQP.markdown b/docs/modules/AMQP.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## AMQP Module
+# AMQP Module
 
 This module interacts with message broker software that implements
 the Advanced Message Queuing Protocol (AMQP) standard. For example, RabbitMQ.
diff --git a/docs/modules/Cli.markdown b/docs/modules/Cli.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## Cli Module
+# Cli Module
 
 ### Actions
 
diff --git a/docs/modules/Db.markdown b/docs/modules/Db.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## Db Module
+# Db Module
 
 Works with SQL dabatase.
 
diff --git a/docs/modules/Dbh.markdown b/docs/modules/Dbh.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## Dbh Module
+# Dbh Module
 
 This module replaces Db module for functional and unit testing, and requires PDO instance to be set.
 Be default it will cover all database queries into transaction and rollback it afterwards.
diff --git a/docs/modules/Doctrine1.markdown b/docs/modules/Doctrine1.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## Doctrine1 Module
+# Doctrine1 Module
 
 Performs DB operations with Doctrine ORM 1.x
 
diff --git a/docs/modules/Doctrine2.markdown b/docs/modules/Doctrine2.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## Doctrine2 Module
+# Doctrine2 Module
 
 Allows integration and testing for projects with Doctrine2 ORM.
 
diff --git a/docs/modules/Filesystem.markdown b/docs/modules/Filesystem.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## Filesystem Module
+# Filesystem Module
 
 Module for testing local filesystem.
 Fork it to extend the module for FTP, Amazon S3, others.
diff --git a/docs/modules/Kohana.markdown b/docs/modules/Kohana.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## Kohana Module
+# Kohana Module
 
 This module provides integration with [Kohana](http://kohanaframework.org/) v3.
 Current status is PRE ALFA=)
diff --git a/docs/modules/Memcache.markdown b/docs/modules/Memcache.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## Memcache Module
+# Memcache Module
 
 Connects to [memcached](http://www.memcached.org/) using either _Memcache_ or _Memcached_ exitnsion.
 
diff --git a/docs/modules/MongoDb.markdown b/docs/modules/MongoDb.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## MongoDb Module
+# MongoDb Module
 
 Works with MongoDb database.
 
diff --git a/docs/modules/PhpBrowser.markdown b/docs/modules/PhpBrowser.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## PhpBrowser Module
+# PhpBrowser Module
 
 Uses [Mink](http://mink.behat.org) with [Goutte](https://github.com/fabpot/Goutte) and [Guzzle](http://guzzlephp.org/) to interact with your application over CURL.
 
diff --git a/docs/modules/REST.markdown b/docs/modules/REST.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## REST Module
+# REST Module
 
 Module for testing REST WebService.
 
diff --git a/docs/modules/Redis.markdown b/docs/modules/Redis.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## Redis Module
+# Redis Module
 
 Works with Redis database.
 
diff --git a/docs/modules/SOAP.markdown b/docs/modules/SOAP.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## SOAP Module
+# SOAP Module
 
 Module for testing SOAP WSDL web services.
 Send requests and check if response matches the pattern.
diff --git a/docs/modules/Selenium.markdown b/docs/modules/Selenium.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## Selenium Module
+# Selenium Module
 
 
 Uses Mink to launch and manipulate Selenium Server (formerly the Selenium RC Server).
diff --git a/docs/modules/Selenium2.markdown b/docs/modules/Selenium2.markdown
@@ -3,7 +3,7 @@ layout: doc
 title: Codeception - Documentation
 ---
 
-## Selenium2 Module
+# Selenium2 Module
 
 Uses Mink to manipulate Selenium2 WebDriver
 
@@ -584,9 +584,9 @@ Example:
 {% highlight php %}
 
 <?php
-## switch to iframe
+# switch to iframe
 $I->switchToIFrame("another_frame");
-## switch to parent page
+# switch to parent page
 $I->switchToIFrame();
 
 
@@ -612,9 +612,9 @@ Example:
 
 <?php
 $I->click("Open window");
-## switch to another window
+# switch to another window
 $I->switchToWindow("another_window");
-## switch to parent window
+# switch to parent window
 $I->switchToWindow();
 
 
diff --git a/docs/modules/SocialEngine.markdown b/docs/modules/SocialEngine.markdown
diff --git a/docs/modules/Symfony1.markdown b/docs/modules/Symfony1.markdown
diff --git a/docs/modules/Symfony2.markdown b/docs/modules/Symfony2.markdown
diff --git a/docs/modules/Unit.markdown b/docs/modules/Unit.markdown
diff --git a/docs/modules/WebDebug.markdown b/docs/modules/WebDebug.markdown
diff --git a/docs/modules/XMLRPC.markdown b/docs/modules/XMLRPC.markdown
diff --git a/docs/modules/ZF1.markdown b/docs/modules/ZF1.markdown
diff --git a/docs/modules/ZombieJS.markdown b/docs/modules/ZombieJS.markdown

Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+`
	`2`	`+Previous Chapter: [Modules](/docs/03-Modules)`
	`3`	`+Next Chapter: [FunctionalTests](/docs/05-FunctionalTests)`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,2 @@`
	`1`	`+`
	`2`	`+Previous Chapter: [WebServices](/docs/10-WebServices)`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+`
	`2`	`+Previous Chapter: [UnitTests-CEST](/docs/08-UnitTests-CEST)`
	`3`	`+Next Chapter: [WebServices](/docs/10-WebServices)`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+`
	`2`	`+Previous Chapter: [AcceptanceTests](/docs/04-AcceptanceTests)`
	`3`	`+Next Chapter: [UnitTests-TEST](/docs/06-UnitTests-TEST)`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+`
	`2`	`+Previous Chapter: [Introduction](/docs/01-Introduction)`
	`3`	`+Next Chapter: [Modules](/docs/03-Modules)`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,2 @@`
	`1`	`+`
	`2`	`+Next Chapter: [GettingStarted](/docs/02-GettingStarted)`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+`
	`2`	`+Previous Chapter: [GettingStarted](/docs/02-GettingStarted)`
	`3`	`+Next Chapter: [AcceptanceTests](/docs/04-AcceptanceTests)`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+`
	`2`	`+Previous Chapter: [UnitTestsScenarios](/docs/07-UnitTestsScenarios)`
	`3`	`+Next Chapter: [Data](/docs/09-Data)`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+`
	`2`	`+Previous Chapter: [FunctionalTests](/docs/05-FunctionalTests)`
	`3`	`+Next Chapter: [UnitTestsScenarios](/docs/07-UnitTestsScenarios)`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+`
	`2`	`+Previous Chapter: [UnitTests-TEST](/docs/06-UnitTests-TEST)`
	`3`	`+Next Chapter: [UnitTests-CEST](/docs/08-UnitTests-CEST)`