Merge pull request #200 from pborreli/typos

Fixed typos

docs/03-ModulesAndHelpers.md

@@ -151,7 +151,7 @@ For `dontSeeClassExist`, the `assertFalse` will be called.
 
 ### Resolving Collisions
 
-What happens if you have two modules which conatins the same named actions?
+What happens if you have two modules which contains the same named actions?
 Codeception allows you to override actions by changing the module order.
 The action from the second module will be loaded and the action from the first will be ignored.
 The order of the modules can be defined in the suite config.
@@ -175,7 +175,7 @@ function reconnectToDatabase() {
 ?>
 ```
 By using the `getModule` function you get access to all of the public methods and properties of the requested module.
-The dbh property was defined as public specificallty to be available to other modules.
+The dbh property was defined as public specifically to be available to other modules.
 
 That technique may be also useful if you need to perform a sequence of actions taken from other modules.
 

docs/04-AcceptanceTests.md

@@ -337,7 +337,7 @@ class WebHelper extends \Codeception\Module {
 ```
 
 We [connected a module](http://codeception.com/docs/03-ModulesAndHelpers#Connecting-Modules), then we retrieved content from Mink session class.
-You should definetely learn Mink to dig deeper.
+You should definitely learn Mink to dig deeper.
 And in the end we performed assertion on current content.
 
 ## Conclusion

docs/05-FunctionalTests.md

@@ -11,7 +11,7 @@ Modules for all of these frameworks share the same interface, and thus your test
 
 ``` php
 <?php
-$I = new TestGuy($scenatio);
+$I = new TestGuy($scenario);
 $I->amOnPage('/');
 $I->click('Login');
 $I->fillField('Username','Miles');
@@ -37,14 +37,14 @@ As you know, `header` function triggers an error if it is executed more then onc
 #### Shared Memory
 
 In functional testing unlike the traditional way, PHP application does not stop after it finished processing a request. 
-As all requests run in one memory conrainer they are not isolated. 
+As all requests run in one memory container they are not isolated.
 So **if you see that your tests are mysteriously failing when they shouldn't - try to execute a single test.**
-This will check if tests were isolated during run. Because it's realy easy to spoil environment as all tests are run in shared memory.
+This will check if tests were isolated during run. Because it's really easy to spoil environment as all tests are run in shared memory.
 Keep your memory clean, avoid memory leaks and clean global and static variables.
 
 ## Starting Functional
 
-You have a functional testtiin suite in `tests/functional` dir.
+You have a functional testing suite in `tests/functional` dir.
 To start you need to include one of the framework's module in suite config file: `tests/functional.suite.yml`.
 Examples on framework configurations you will find below th this chapter.
 
@@ -154,7 +154,7 @@ Develop a module, try it and share with community.
 #### Any Other
 
 Integration is a bit harder if your framework is not using HttpKernel component.
-The hardest part of it is resolving commong pitfalls: memory management, and usage of `headers` function.
+The hardest part of it is resolving common pitfalls: memory management, and usage of `headers` function.
 Codeception uses [BrowserKit](https://github.com/symfony/BrowserKit) from the Symfony Components to interact with applications in functional tests. This component provides all of the common actions we see in modules: click, fillField, see, etc... So you don't need to write these methods in your module. For the integration you should provide a bridge from BrowserKit to your application.
 
 We will start with writing a helper class for framework integration.

docs/06-UnitTests.md

@@ -18,7 +18,7 @@ $ php codecept.phar generate:phpunit unit Simple
 ```
 
 Codeception has it's addons to standard unit tests. So let's try them.
-We need another command to create Codecption-powered unit tests.
+We need another command to create Codeception-powered unit tests.
 
 ```bash
 $ php codecept.phar generate:test unit Simple
@@ -69,7 +69,7 @@ modules:
 
 ### Testing Database
 
-Probably, there is no very useful modules set up by default for CodeGuy class. Thet's because the CodeGuy class is mostly used for scenario-driven unit tests, described in next chapters. But that's ok, we can get a use of it by adding modules we need. For example, we can add a Db module to test updates in database.
+Probably, there is no very useful modules set up by default for CodeGuy class. That's because the CodeGuy class is mostly used for scenario-driven unit tests, described in next chapters. But that's ok, we can get a use of it by adding modules we need. For example, we can add a Db module to test updates in database.
 
 ```yaml
 # Codeception Test Suite Configuration

docs/08-CestFormat.md

@@ -23,7 +23,7 @@ class UserCest {
 ?>
 ```
 
-Before proceeding, please make sure you executed `build` command that creats a `CodeGuy` class with methods from [Unit](http://codeception.com/docs/modules/Unit) module.
+Before proceeding, please make sure you executed `build` command that creates a `CodeGuy` class with methods from [Unit](http://codeception.com/docs/modules/Unit) module.
 
 ```
 php codecept.phar build
@@ -35,7 +35,7 @@ Let's create first test with `generate:cest` command:
 $ php codecept.phar generate:cest unit Post
 ```
 
-At first we need to define with `$class` preoperty the class which is being actually tested.
+At first we need to define with `$class` property the class which is being actually tested.
 
 ```php
 <?php
@@ -53,7 +53,7 @@ class PostCest {
 
 This will create an empty Cest file for us.
 
-There are many cases whre we test only one method of a class. As we discovered, it's quite easy to define the class and method you are going to test. We take the `$class` parameter of the Cest class, and the method's name as a target method.
+There are many cases where we test only one method of a class. As we discovered, it's quite easy to define the class and method you are going to test. We take the `$class` parameter of the Cest class, and the method's name as a target method.
 
 ```php
 <?php
@@ -176,7 +176,7 @@ class ControllerCest {
 
 #### Is The Test Running?
 
-Scenario-based test is run in 2 phases: analysis and execution. Whenever you want to add any custom PHP code (which doesn't use the $I object) you probably want it to be xecuted in the runtime. Thus, you should always perform the check if the test is running:
+Scenario-based test is run in 2 phases: analysis and execution. Whenever you want to add any custom PHP code (which doesn't use the $I object) you probably want it to be executed in the runtime. Thus, you should always perform the check if the test is running:
 
 ```php
 <?php

docs/09-Data.md

@@ -8,7 +8,7 @@ When we choose to clean up a database, we should make this cleaning as fast as p
 
 ## Manual Cleanup
 
-You could possibly create records at the begining of test and delete them afterwards. This is cool option if you don't have shared data between tests.
+You could possibly create records at the beginning of test and delete them afterwards. This is cool option if you don't have shared data between tests.
 But you shouldn't put any code into your test file. Because test files are parsed two times: for analysis and execution, this may lead to unpredictable results. So, you should specify when do you want your code to be executed. It's a good idea to create data before the analysis and remove data after the test is finished. Use the special methods `running()` and `preload()` of `$scenario` object to determine the current object state.
 
 ``` php
@@ -31,7 +31,7 @@ if ($scenario->running()) {
 
 Similarly you can insert any code before into your test. But please explicitly set the stage when you need it to be included, or the code will be executed twice!
 
-## Automatical Cleanup
+## Automatic Cleanup
 
 Codeception has a Db module, which takes on most of the tasks of database interaction. By default it will try to repopulate the database from a dump and clean it up after each test. This module expects a database dump in SQL format. It's already prepared for configuration in codeception.yml
 
@@ -51,7 +51,7 @@ The Db module is a rough tool. It works for any type of database supported by PD
 
 ## Separate connections
 
-In acceptance tests, your test is interacting with the application through a web server. There is no way to receive a database connection from the web server. This means that the test and the application will work with the same database but on different connections. Provide in the Db module the same credentials that your application uses, and then you can access the database for assertions (`seeInDabatase` actions) and perform automatic cleanups.
+In acceptance tests, your test is interacting with the application through a web server. There is no way to receive a database connection from the web server. This means that the test and the application will work with the same database but on different connections. Provide in the Db module the same credentials that your application uses, and then you can access the database for assertions (`seeInDatabase` actions) and perform automatic cleanups.
 
 ### Speedup with SQLite
 
@@ -76,7 +76,7 @@ Before the test suite is started, the SQLite database is created and copied. Aft
 ## Shared connections
 
 When an application or it's parts are run within the Codeception process, you can use your application connection in your tests. 
-If you can access the connection, all database operations can be put into one global transaction and rolled back at the end. That will dramatically improve performance. Nothing will be written tothe database at the end, thus no database repopulation is actually needed.
+If you can access the connection, all database operations can be put into one global transaction and rolled back at the end. That will dramatically improve performance. Nothing will be written to the database at the end, thus no database repopulation is actually needed.
 
 ### ORM modules
 
@@ -131,7 +131,7 @@ $davert = Doctrine::getTable('User')->findOneBy('name', 'davert');
 ?>
 ```
 
-Fixture usage in a sample accetpance or functional test.
+Fixture usage in a sample acceptance or functional test.
 
 ```php
 <?php

docs/11-Codecoverage.md

@@ -1,8 +1,8 @@
 ## Code Coverage
 
-At some point you want to review which parts of your appliaction are tested well and which are not. 
+At some point you want to review which parts of your application are tested well and which are not.
 Just for this case the [CodeCoverage](http://en.wikipedia.org/wiki/Code_coverage) is used. When you execute your tests to collect coverage report, 
-you will receive statisitcs of all classes, methods, and lines triggered by these tests. 
+you will receive statistics of all classes, methods, and lines triggered by these tests.
 The ratio between all lines in script and all touched lines is a main coverage criteria. In the ideal world you should get a 100% code coverage,
 but in reality 80% are just enough. And even 100% code coverage rate doesn't save you from fatal errors and crashes. 
 
@@ -75,26 +75,26 @@ codecept run --coverage --xml --html
 ```
 
 XML and HTML reports are stored to the `_logs` directory. The best way to review report is to open `index.html` from `tests/_logs/coverage` in your browser.
-XML clover reports are used by IDEs (like PHPStorm) or Conitinious Integration servers (Like Jenkins).
+XML clover reports are used by IDEs (like PHPStorm) or Continuous Integration servers (Like Jenkins).
 
 ## Remote CodeCoverage
 
 If you run your application via Webserver (Apache, Nginx, PHP WebServer) you don't have a direct access to tested code, 
 so collecting coverage becomes a non-trivial task. The same goes to scripts that are tested on different node. 
 To get access to this code you need `xdebug` installed with `remote_enable` option turned on. 
 Codeception also requires a little spy to interact  with your application. As your application run standalone, 
-without even knowing it is being tested, a small file should be included in order to collecto coverage info. 
+without even knowing it is being tested, a small file should be included in order to collect coverage info.
 
 This file is called `c3.php` and is [available on GitHub](https://github.com/Codeception/c3). 
 `c3.php` should be downloaded and included in your application in a very first line of it's from controller. 
-By sending special headers Codeception will command your appliaction when to start codecoverage collection and when to stop it.
+By sending special headers Codeception will command your application when to start codecoverage collection and when to stop it.
 After the suite is finished, a report will be stored and Codeception will grab it from your application. 
 
 Please, follow installation instructions described in a [readme file](https://github.com/Codeception/c3).
 
 After the `c3.php` file is included in application you can start gather coverage. 
 In case you execute your application locally there is nothing to be changed in config.
-All codecoverage reports will be collected as usual and marged afterwards.
+All codecoverage reports will be collected as usual and merged afterwards.
 Think of it: Codeception runs remote coverage in the same way as local. 
 
 It's never been easier to setup remote codecoverage for your application. In ay other framework. Really.
@@ -114,7 +114,7 @@ But in case of running tests on a remote server we are not sure of it.
 
 ## Conclusion
 
-It's never been easier to setup local and remote code coverage. Just one config and one additional file to incldue! 
+It's never been easier to setup local and remote code coverage. Just one config and one additional file to include!
 **With Codeception you can easily generate CodeCoverage reports for your Selenium tests** (or other acceptance or api tests). Mixing reports for `acceptance`, `functional`, and `unit` suites provides 
 you the most complete information on which parts of your applications are tested and which are not.
 

docs/modules/Db.md

@@ -2,7 +2,7 @@
 **For additional reference, please review the [source](https://github.com/Codeception/Codeception/tree/master/src/Codeception/Module/Db.php)**
 
 
-Works with SQL dabatase.
+Works with SQL database.
 
 The most important function of this module is cleaning database before each test.
 That's why this module was added into global configuration file: codeception.yml.
@@ -23,7 +23,7 @@ Supported and tested databases are:
 Supported but not tested.
 
 * MSSQL
-* Orcale
+* Oracle
 
 Connection is done by database Drivers, which are stored in Codeception\Util\Driver namespace.
 Check out drivers if you get problems loading dumps and cleaning databases.

docs/modules/Dbh.md

@@ -35,7 +35,7 @@ This module despite of it's stability may act unstable because of transactions i
 
 * cleanup: true - enable cleanups by covering all queries inside transaction.
 
-### Examlple
+### Example
 
     modules: 
        enabled: [Dbh]

docs/modules/Doctrine2.md

@@ -23,7 +23,7 @@ It can be done in bootstrap file, by setting static $em property:
 
 ## Config
 
-* auto_connect: true - tries to get EntityManager through connected frameworks. If none found expects the $em values specified as discribed above.
+* auto_connect: true - tries to get EntityManager through connected frameworks. If none found expects the $em values specified as described above.
 * cleanup: true - all doctrine queries will be run in transaction, which will be rolled back at the end of test.
 
  ### Example (`functional.suite.yml`)

docs/modules/Memcache.md

@@ -2,7 +2,7 @@
 **For additional reference, please review the [source](https://github.com/Codeception/Codeception/tree/master/src/Codeception/Module/Memcache.php)**
 
 
-Connects to [memcached](http://www.memcached.org/) using either _Memcache_ or _Memcached_ exitnsion.
+Connects to [memcached](http://www.memcached.org/) using either _Memcache_ or _Memcached_ extension.
 
 Performs a cleanup by flushing all values after each test run.
 

docs/modules/Selenium.md

@@ -422,7 +422,7 @@ $I->seeCheckboxIsChecked('//form/input[@type=checkbox and  * name=agree]');
 
 Checks element visibility.
 Fails if element exists but is invisible to user.
-Eiter CSS or XPath can be used.
+Either CSS or XPath can be used.
 
  * param $selector
 
@@ -514,15 +514,15 @@ $I->uncheckOption('#notify');
 ### wait
 
 
-Wait for x miliseconds
+Wait for x milliseconds
 
- * param $miliseconds
+ * param $milliseconds
 
 
 ### waitForJS
 
 
-Waits for x miliseconds or until JS condition turns true.
+Waits for x milliseconds or until JS condition turns true.
 
- * param $miliseconds
+ * param $milliseconds
  * param $jsCondition

docs/modules/Selenium2.md

@@ -457,7 +457,7 @@ $I->seeCheckboxIsChecked('//form/input[@type=checkbox and  * name=agree]');
 
 Checks element visibility.
 Fails if element exists but is invisible to user.
-Eiter CSS or XPath can be used.
+Either CSS or XPath can be used.
 
  * param $selector
 
@@ -612,15 +612,15 @@ $I->uncheckOption('#notify');
 ### wait
 
 
-Wait for x miliseconds
+Wait for x milliseconds
 
- * param $miliseconds
+ * param $milliseconds
 
 
 ### waitForJS
 
 
-Waits for x miliseconds or until JS condition turns true.
+Waits for x milliseconds or until JS condition turns true.
 
- * param $miliseconds
+ * param $milliseconds
  * param $jsCondition

docs/modules/Symfony1.md

@@ -5,7 +5,7 @@
 Module that interacts with Symfony 1.4 applications.
 
 Replaces functional testing framework from symfony. Authorization features uses Doctrine and sfDoctrineGuardPlugin.
-Uses native symfony connections and test classes. Provides additional invormations on every actions.
+Uses native symfony connections and test classes. Provides additional informations on every actions.
 
 If test fails stores last shown page in 'log' dir.
 

docs/modules/ZF1.md

@@ -20,7 +20,7 @@ and LIBRARY_PATH set to './library'. If it's not then set the appropriate path i
 
 * env  - environment used for testing ('testing' by default).
 * config - relative path to your application config ('application/configs/application.ini' by default).
-* app_path - relative path to your application folder ('applicaiton' by default).
+* app_path - relative path to your application folder ('application' by default).
 * lib_path - relative path to your library folder ('library' by default).
 
 ## API
@@ -37,7 +37,7 @@ Unfortunately Zend_Db doesn't support nested transactions, thus, for cleaning yo
 [implement nested transactions yourself](http://blog.ekini.net/2010/03/05/zend-framework-how-to-use-nested-transactions-with-zend_db-and-mysql/).
 
 If your database supports nested transactions (MySQL doesn't) or you implemented them you can put all your code inside a transaction.
-Use a generated helper TestHelper. Usse this code inside of it.
+Use a generated helper TestHelper. Use this code inside of it.
 
 ``` php
 <?php

docs/modules/ZombieJS.md

@@ -426,7 +426,7 @@ $I->seeCheckboxIsChecked('//form/input[@type=checkbox and  * name=agree]');
 
 Checks element visibility.
 Fails if element exists but is invisible to user.
-Eiter CSS or XPath can be used.
+Either CSS or XPath can be used.
 
  * param $selector
 
@@ -518,15 +518,15 @@ $I->uncheckOption('#notify');
 ### wait
 
 
-Wait for x miliseconds
+Wait for x milliseconds
 
- * param $miliseconds
+ * param $milliseconds
 
 
 ### waitForJS
 
 
-Waits for x miliseconds or until JS condition turns true.
+Waits for x milliseconds or until JS condition turns true.
 
- * param $miliseconds
+ * param $milliseconds
  * param $jsCondition

plugins/DocBlox/Codeception/plugin.xml

@@ -5,7 +5,7 @@
     <version>1.0.0</version>
     <author>Michael Bodnarchuk "Davert"</author>
     <email>codeception@davert.mail.ua</email>
-    <description>Adds documenation generated from Codeception tests</description>
+    <description>Adds documentation generated from Codeception tests</description>
     <website>http://www.codeception.com</website>
     <class-prefix>DocBlox_Plugin_Codeception</class-prefix>
     <listener>Listener</listener>