changed unit tests to use tester property instead of CodeGuy

Author: DavertMik

docs/01-Introduction.md

@@ -14,17 +14,17 @@ Let's review the listed testing paradigms in reverse order.
 
 ### Acceptance Tests
 
-How does your client, manager, or tester, or any other non-technical person, know your site is working? She opens the browser, enters the site, clicks on links, fills the forms, and sees the proper pages as a result. She has no idea of the framework, database, web-server, or programming language you are using. If she sees improper behavior, she will create a bug report. Still this person has no idea why the application didn't work as expected.
+How does your client, manager, or tester, or any other non-technical person, know your site is working? By opening browser, accessing a site, clicking on links, filling the forms, and actually seeing the contant on a web page. That person has no idea of the framework, database, web-server, or programming language you use or why application did not behave as it was expected.
 
-Acceptance tests can cover standard but complex scenarios from a user perspective. With acceptance tests you can be confident that users, following all defined scenarios, won't get errors. 
+Acceptance tests can cover standard but complex scenarios from a user's perspective. With acceptance tests you can be confident that users, following all defined scenarios, won't get errors. 
 
-Please, note that **any site** can be covered with acceptance tests. Even if you use a very custom CMS or framework.
+Please, note that **any web site** can be covered with acceptance tests. Even if you use a very custom CMS or framework.
 
 #### Sample acceptance test
 
-``` php
+```php
 <?php
-$I = new WebGuy($scenario);
+$I = new AcceptanceTester($scenario);
 $I->amOnPage('/');
 $I->click('Sign Up');
 $I->submitForm('#signup', array('username' => 'MilesDavis', 'email' => 'miles@davis.com'));
@@ -37,29 +37,28 @@ $I->see('Thank you for Signing Up!');
 * can be run on any website
 * can test javascript and ajax requests
 * can be shown to your clients and managers
-* the most stable: less affected by changes in source code or technologies.
+* most stable in support: less affected by changes in source code or technologies.
 
 #### Cons
-* fewer checks can lead to false-positive results
 * the slowest: requires running browser and database repopulation.
+* fewer checks can lead to false-positive results
 * yep, they are really slow.
+* not stable in execution: rendering and javascript issues, can lead to unpredicted results. 
 
 
 ### Functional Tests
 
-Let's say your application is tested by a technically advanced guy. He also opens the browser, enters the site, clicks links and submits forms, but when an error occurs he can report to you the exception that was thrown, or check the database for expected values. This guy already knows some aspects of your application, and by knowing that his tests can cover more technical details.
+What if we could check our application without running it on a server? In this way we could see detailed exceptions on errors, have tests running faster, and check database for values we expect. That's a are what functional tests are for.
 
-Functional tests are run without browser emulation. For functional tests you emulate a web request and submit it to your application. It should return to you a response. You can make assertions about the response, and also access the application's internal values.
+For functional tests you emulate a web request ($_GET, $_POST variables) and send it into your application which returns HTML response. Inside a test you can make assertions about the response, also you can check the data was succesfully stored into database.
 
-For functional tests your application should be prepared to be run in test mode. For frameworks like Symfony2, Symfony1, or Zend, it's easy to start an application in test mode. 
-
-Codeception provides connectors to several popular PHP frameworks, but you can write your own.
+For functional tests your application should be prepared to be run in test environment. Codeception provides connectors to several popular PHP frameworks, but you can write your own.
 
 #### Sample functional test
 
 ```php
 <?php
-$I = new TestGuy($scenario);
+$I = new FunctionalTester($scenario);
 $I->amOnPage('/');
 $I->click('Sign Up');
 $I->submitForm('#signup', array('username' => 'MilesDavis', 'email' => 'miles@davis.com'));
@@ -84,9 +83,7 @@ $I->seeInDatabase('users', array('email' => 'miles@davis.com'));
 
 ### Unit Tests
 
-Only the developer understands how and what is tested here. It can be either unit or integration tests, but they are limited to check one method per test.
-
-The only difference between unit tests and integration tests is that a unit test should be run in total isolation. All other classes or methods should be replaced with stubs. 
+Testing pieces of code before coupling them together is highly important as well. This way you can be sure that some deeply hidden feature still works, even it was not touched by functional or acceptance tests. This also proves you produced stable and testable code.
 
 Codeception is created on top of [PHPUnit](http://www.phpunit.de/). If you have experience writing unit tests with PHPUnit you can continue doing so. Codeception has no problem executing standard PHPUnit tests. 
 
@@ -103,25 +100,25 @@ function testSavingUser()
     $user->setSurname('Davis');
     $user->save();
     $this->assertEquals('Miles Davis', $user->getFullName());
-    $this->codeGuy->seeInDatabase('users',array('name' => 'Miles', 'surname' => 'Davis'));
+    $this->unitTester->seeInDatabase('users',array('name' => 'Miles', 'surname' => 'Davis'));
 }
 ?>
 ```
 
 #### Pros
 
-* fast as hell (well, in the current example, you still need database repopulation).
+* fastest (well, in the current example, you still need database repopulation).
 * can cover rarely used features.
 * can test stability of application core.
 * you can only be considered a good developer if you write them :)
 
 #### Cons
 
 * doesn't test connections between units.
-* most unstable: very sensitive to code changes.
+* unstable in support: very sensitive to code changes.
 
 ## Conclusion
 
-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.
+Despite the wide popularity of TDD, not all 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.

docs/02-GettingStarted.md

@@ -2,19 +2,20 @@
 
 Let's take a look into Codeception architecture. We assume that you already [installed](http://codeception.com/install) it, and bootstrapped your first test suites. Codeception has generated three of them: unit, functional, and acceptance. They are well described in the previous chapter. Inside your __/tests__ folder you will have three config files and three directories with names corresponding to these suites. Suites are independent groups of tests with a common purpose. 
 
-## Actors (Guys)
+## Actors
 
-One of the main concepts of Codeception is representation of tests as actions of a person. By default we call this person a Guy (but you may choose different naming on bootstrap). We have a CodeGuy, who executes functions and tests the code. We also have a TestGuy, a qualified tester, who tests the application as a whole, with knowledge of its internals. And a WebGuy, a user who works with our application through an interface that we provide.
+One of the main concepts of Codeception is representation of tests as actions of a person. We have a UnitTester, who executes functions and tests the code. We also have a FunctionalTester, a qualified tester, who tests the application as a whole, with knowledge of its internals. And a AcceptanceTester, a user who works with our application through an interface that we provide.
 
-Each of these Guys are PHP classes along with the actions that they are allowed to do. As you can see, each of these Guys have different abilities. They are not constant, you can extend them. You can create new Guys If you like, but one Guy belongs to one suite. You can see the Guy classes inside the suite directories.
+Each of these Actors are PHP classes along with the actions that they are allowed to do. As you can see, each of these Actors have different abilities. They are not constant, you can extend them. One Actor belongs to one testing suite. 
 
-Guy classes are not written, they are generated by the build command:
+Actor classes are not written but generated from suite configuration. When you change configuration actor classes are **rebuilt automatically**.
+
+If Actor classes are not created or updated as you expect, try to generate them manually with `build` command:
 
 ```
 $ php codecept.phar build
 ```
 
-Guy classes are generated from suite configuration. When you change configuration guy classes will be rebuilt automatically.
 
 ## Writing a Sample Scenario
 
@@ -30,17 +31,17 @@ $ php codecept.phar generate:cept acceptance Signin
 
 ```php
 <?php
-$I = new WebGuy($scenario);
+$I = new AcceptanceTester($scenario);
 ?>
 ```
 
-A Scenario always starts with Guy class initialization. After that, writing a scenario is just like typing `$I->` and choosing a proper action from the auto-completion list.
+A Scenario always starts with Actor class initialization. After that, writing a scenario is just like typing `$I->` and choosing a proper action from the auto-completion list.
 
 Let's sign in to our site. We assume that we have a 'login' page where we are getting authenticated by login and password. Then we are moved to a user page, where we see the text `Hello, %username%`. Let's look at how this scenario is written in Codeception.
 
-``` php
+```php
 <?php
-$I = new WebGuy($scenario);
+$I = new AcceptanceTester($scenario);
 $I->wantTo('log in as regular user');
 $I->amOnPage('/login');
 $I->fillField('Username','davert');
@@ -50,32 +51,32 @@ $I->see('Hello, davert');
 ?>
 ```
 
-Before we execute this test, we should make sure that the site is running on a local web server. Open the `tests/acceptance.suite.yml` file and replace the URL with the URL of your web application:
+Before we execute this test, we should make sure that the site is running on a local web server. Let's open the `tests/acceptance.suite.yml` file and replace the URL with the URL of your web application:
 
 ``` yaml
 config:
     PhpBrowser:
         url: 'http://myappurl.local'
 ```
 
-If you don't have a web server running, you can use the [PHP Built-in Web Server](http://php.net/manual/en/features.commandline.webserver.php) which is available in PHP 5.4. 
-
-After you set the proper URL, you can run this test with the command:
+After we configured utl we can run this test with `run` command:
 
 ``` bash
 $ php codecept.phar run
 ```
 
-In the output you should see: 
+Here is the output we should see: 
 
 ``` bash
-Suite acceptance started
-Trying log in as regular user (SigninCept.php) - Ok
+Acceptance Tests (1) -------------------------------
+Trying log in as regular user (SigninCept.php)   Ok
+----------------------------------------------------
 
-Suite functional started
-
-Suite unit started
+Functional Tests (0) -------------------------------
+----------------------------------------------------
 
+Unit Tests (0) -------------------------------------
+----------------------------------------------------
 
 Time: 1 second, Memory: 21.00Mb
 
@@ -91,7 +92,7 @@ $ php codecept.phar run acceptance --steps
 We should see a step-by-step report on the performed actions.
 
 ```bash
-Suite acceptance started
+Acceptance Tests (1) -------------------------------
 Trying to log in as regular user (SigninCept.php)
 Scenario:
 * I am on page "/login"
@@ -100,7 +101,7 @@ Scenario:
 * I click "Login"
 * I see "Hello, davert"
   OK
-
+----------------------------------------------------  
 
 Time: 0 seconds, Memory: 21.00Mb
 
@@ -114,13 +115,11 @@ Give it a try!
 
 ## Modules and Helpers
 
-The actions in Guy classes are taken from modules. With the `build` command described above, Codeception emulates multiple inheritance. Modules are designed to have one action performed with one method. According to the [DRY principle](http://en.wikipedia.org/wiki/Don%27t_repeat_yourself), if you use the same scenario components in different modules, you can combine them and move them to a custom module. By default each suite has an empty module, which can extend Guy classes. They are stored in the ___helpers__ directory.
+The actions in Actor classes are taken from modules. Generated Actor classes emulate multiple inheritance. Modules are designed to have one action performed with one method. According to the [DRY principle](http://en.wikipedia.org/wiki/Don%27t_repeat_yourself), if you use the same scenario components in different modules, you can combine them and move them to a custom module. By default each suite has an empty module, which can be used to extend Actor classes. They are stored in the ___support__ directory.
 
 ## Bootstrap
 
-Each suite has its own bootstrap file. It's located in the suite directory and is named `_bootstrap.php`. It will be executed before each test.
-
-Write any setup preparations for the suite there.
+Each suite has its own bootstrap file. It's located in the suite directory and is named `_bootstrap.php`. It will be executed before test suite.
 
 ## Test Formats
 
@@ -175,7 +174,7 @@ To generate JUnit XML output you can provide `--xml` option, and `--html` for HT
 $ php codecept.phar run --steps --xml --html
 ```
 
-This command will run all tests for all suites, displaying the steps, and building HTML and XML reports. Reports will be store in `tests/_log/` directory.
+This command will run all tests for all suites, displaying the steps, and building HTML and XML reports. Reports will be store in `tests/_output/` directory.
 
 And to learn all available options:
 
@@ -202,4 +201,4 @@ 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.