Skip to content

Commit 1b13af8

Browse files
DavertMikDavertMik
committed
auto updated documentation
1 parent 77a5166 commit 1b13af8

59 files changed

Lines changed: 22844 additions & 12 deletions

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎docs/01-Introduction.md‎

Lines changed: 134 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,135 @@
1+
---
2+
layout: doc
3+
title: Introduction - Codeception - Documentation
4+
---
15

2-
Next Chapter: [GettingStarted](/docs/02-GettingStarted)
6+
# Introduction
7+
8+
The idea behind testing is not new. You can't sleep well if you are not confident that your last commit didn't take down the whole application.
9+
Having your application covered with tests gives you more trust in the stability of your application. That's all.
10+
11+
In most cases tests don't guarantee that the application works 100% as it is supposed to. You can't predict all possible scenarios and exceptional situations for complex apps.
12+
But you can cover with tests the most important parts of your app and at least be sure they work as predicted.
13+
14+
There are plenty of ways to test your application. The most popular paradigm is [Unit Testing](http://en.wikipedia.org/wiki/Unit_testing). As for web applications, testing the controller, or model in isolation doesn't prove your application is working. To test the behavior of your application as a whole, you should write functional or acceptance tests.
15+
16+
The Codeception testing framework distinguishes these levels of testing. Out of the box you have tools for writing unit, functional, and acceptance tests in a single manner.
17+
18+
Let's review the listed testing paradigms in reverse order.
19+
20+
### Acceptance Tests
21+
22+
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.
23+
24+
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.
25+
26+
Please, note that **any web site** can be covered with acceptance tests. Even if you use a very custom CMS or framework.
27+
28+
#### Sample acceptance test
29+
30+
{% highlight php %}
31+
32+
<?php
33+
$I = new AcceptanceTester($scenario);
34+
$I->amOnPage('/');
35+
$I->click('Sign Up');
36+
$I->submitForm('#signup', array('username' => 'MilesDavis', 'email' => 'miles@davis.com'));
37+
$I->see('Thank you for Signing Up!');
38+
?>
39+
40+
{% endhighlight %}
41+
42+
#### Pros
43+
44+
* can be run on any website
45+
* can test javascript and ajax requests
46+
* can be shown to your clients and managers
47+
* most stable in support: less affected by changes in source code or technologies.
48+
49+
#### Cons
50+
* the slowest: requires running browser and database repopulation.
51+
* fewer checks can lead to false-positive results
52+
* yep, they are really slow.
53+
* not stable in execution: rendering and javascript issues, can lead to unpredicted results.
54+
55+
56+
### Functional Tests
57+
58+
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.
59+
60+
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.
61+
62+
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.
63+
64+
#### Sample functional test
65+
66+
{% highlight php %}
67+
68+
<?php
69+
$I = new FunctionalTester($scenario);
70+
$I->amOnPage('/');
71+
$I->click('Sign Up');
72+
$I->submitForm('#signup', array('username' => 'MilesDavis', 'email' => 'miles@davis.com'));
73+
$I->see('Thank you for Signing Up!');
74+
$I->seeEmailSent('miles@davis.com', 'Thank you for registration');
75+
$I->seeInDatabase('users', array('email' => 'miles@davis.com'));
76+
?>
77+
78+
{% endhighlight %}
79+
80+
#### Pros
81+
82+
* like acceptance tests, but much faster.
83+
* can provide more detailed reports.
84+
* you can still show this code to managers and clients.
85+
* stable enough: only major code changes, or moving to other framework, can break them.
86+
87+
#### Cons
88+
89+
* javascript and ajax can't be tested.
90+
* by emulating the browser you might get more false-positive results.
91+
* require a framework.
92+
93+
### Unit Tests
94+
95+
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.
96+
97+
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.
98+
99+
But Codeception provides some good tools to make your unit tests simpler and cleaner. Even inexperienced developers should understand what is tested and how. Requirements and code can change rapidly, and unit tests should be updated every time to fit requirements. The better you understand the testing scenario, the faster you can update it for new behavior.
100+
101+
#### Sample integration test
102+
103+
{% highlight php %}
104+
105+
<?php
106+
function testSavingUser()
107+
{
108+
$user = new User();
109+
$user->setName('Miles');
110+
$user->setSurname('Davis');
111+
$user->save();
112+
$this->assertEquals('Miles Davis', $user->getFullName());
113+
$this->unitTester->seeInDatabase('users',array('name' => 'Miles', 'surname' => 'Davis'));
114+
}
115+
?>
116+
117+
{% endhighlight %}
118+
119+
#### Pros
120+
121+
* fastest (well, in the current example, you still need database repopulation).
122+
* can cover rarely used features.
123+
* can test stability of application core.
124+
* you can only be considered a good developer if you write them :)
125+
126+
#### Cons
127+
128+
* doesn't test connections between units.
129+
* unstable in support: very sensitive to code changes.
130+
131+
## Conclusion
132+
133+
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.
134+
135+
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/01-Introduction.md.md‎

Lines changed: 140 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,140 @@
1+
---
2+
layout: doc
3+
title: Introduction - Codeception - Documentation
4+
---
5+
6+
# Introduction
7+
8+
The idea behind testing is not new. You can't sleep well if you are not confident that your last commit didn't take down the whole application.
9+
Having your application covered with tests gives you more trust in the stability of your application. That's all.
10+
11+
In most cases tests don't guarantee that the application works 100% as it is supposed to. You can't predict all possible scenarios and exceptional situations for complex apps.
12+
But you can cover with tests the most important parts of your app and at least be sure they work as predicted.
13+
14+
There are plenty of ways to test your application. The most popular paradigm is [Unit Testing](http://en.wikipedia.org/wiki/Unit_testing). As for web applications, testing the controller, or model in isolation doesn't prove your application is working. To test the behavior of your application as a whole, you should write functional or acceptance tests.
15+
16+
The Codeception testing framework distinguishes these levels of testing. Out of the box you have tools for writing unit, functional, and acceptance tests in a single manner.
17+
18+
Let's review the listed testing paradigms in reverse order.
19+
20+
### Acceptance Tests
21+
22+
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.
23+
24+
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.
25+
26+
Please, note that **any web site** can be covered with acceptance tests. Even if you use a very custom CMS or framework.
27+
28+
#### Sample acceptance test
29+
30+
{% highlight php %}
31+
32+
<?php
33+
$I = new AcceptanceTester($scenario);
34+
$I->amOnPage('/');
35+
$I->click('Sign Up');
36+
$I->submitForm('#signup', array('username' => 'MilesDavis', 'email' => 'miles@davis.com'));
37+
$I->see('Thank you for Signing Up!');
38+
?>
39+
40+
{% endhighlight %}
41+
42+
#### Pros
43+
44+
* can be run on any website
45+
* can test javascript and ajax requests
46+
* can be shown to your clients and managers
47+
* most stable in support: less affected by changes in source code or technologies.
48+
49+
#### Cons
50+
* the slowest: requires running browser and database repopulation.
51+
* fewer checks can lead to false-positive results
52+
* yep, they are really slow.
53+
* not stable in execution: rendering and javascript issues, can lead to unpredicted results.
54+
55+
56+
### Functional Tests
57+
58+
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.
59+
60+
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.
61+
62+
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.
63+
64+
#### Sample functional test
65+
66+
{% highlight php %}
67+
68+
<?php
69+
$I = new FunctionalTester($scenario);
70+
$I->amOnPage('/');
71+
$I->click('Sign Up');
72+
$I->submitForm('#signup', array('username' => 'MilesDavis', 'email' => 'miles@davis.com'));
73+
$I->see('Thank you for Signing Up!');
74+
$I->seeEmailSent('miles@davis.com', 'Thank you for registration');
75+
$I->seeInDatabase('users', array('email' => 'miles@davis.com'));
76+
?>
77+
78+
{% endhighlight %}
79+
80+
#### Pros
81+
82+
* like acceptance tests, but much faster.
83+
* can provide more detailed reports.
84+
* you can still show this code to managers and clients.
85+
* stable enough: only major code changes, or moving to other framework, can break them.
86+
87+
#### Cons
88+
89+
* javascript and ajax can't be tested.
90+
* by emulating the browser you might get more false-positive results.
91+
* require a framework.
92+
93+
### Unit Tests
94+
95+
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.
96+
97+
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.
98+
99+
But Codeception provides some good tools to make your unit tests simpler and cleaner. Even inexperienced developers should understand what is tested and how. Requirements and code can change rapidly, and unit tests should be updated every time to fit requirements. The better you understand the testing scenario, the faster you can update it for new behavior.
100+
101+
#### Sample integration test
102+
103+
{% highlight php %}
104+
105+
<?php
106+
function testSavingUser()
107+
{
108+
$user = new User();
109+
$user->setName('Miles');
110+
$user->setSurname('Davis');
111+
$user->save();
112+
$this->assertEquals('Miles Davis', $user->getFullName());
113+
$this->unitTester->seeInDatabase('users',array('name' => 'Miles', 'surname' => 'Davis'));
114+
}
115+
?>
116+
117+
{% endhighlight %}
118+
119+
#### Pros
120+
121+
* fastest (well, in the current example, you still need database repopulation).
122+
* can cover rarely used features.
123+
* can test stability of application core.
124+
* you can only be considered a good developer if you write them :)
125+
126+
#### Cons
127+
128+
* doesn't test connections between units.
129+
* unstable in support: very sensitive to code changes.
130+
131+
## Conclusion
132+
133+
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.
134+
135+
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.
136+
137+
138+
139+
140+
* **Next Chapter: [GettingStarted.md >](/docs/02-GettingStarted.md)**

0 commit comments

Comments
 (0)