You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _includes/extensions.md
+9-6Lines changed: 9 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,21 +41,24 @@ Add to list of enabled extensions
41
41
42
42
``` yaml
43
43
extensions:
44
-
enabled: [Codeception\Extension\Recorder]
44
+
enabled:
45
+
- Codeception\Extension\Recorder
45
46
```
46
47
47
48
#### Configuration
48
49
49
50
* `delete_successful` (default: true) - delete records for successfully passed tests (log only failed and errored)
50
-
* `module` (default: WebDriver) - which module for screenshots to use.
51
-
Module should implement `Codeception\Lib\Interfaces\ScreenshotSaver` interface.
52
-
Currently only WebDriver or any its children can be used.
51
+
* `module` (default: WebDriver) - which module for screenshots to use. Set `AngularJS` if you want to use it with AngularJS module. Generally, module should implement `Codeception\Lib\Interfaces\ScreenshotSaver` interface.
52
+
53
+
54
+
#### Examples:
53
55
54
56
``` yaml
55
57
extensions:
56
-
config:
58
+
enabled:
57
59
Codeception\Extension\Recorder:
58
-
delete_successful: false
60
+
module: AngularJS # enable for Angular
61
+
delete_successful: false # show successful reports
Copy file name to clipboardExpand all lines: changelog.markdown
+69Lines changed: 69 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,75 @@ title: Codeception Changelog
7
7
8
8
# Changelog
9
9
10
+
#### 2.2.7
11
+
12
+
***Config validation** with `codecept config:validate` command. Use it:
13
+
14
+
```
15
+
codecept config:validate
16
+
codecept config:validate acceptance
17
+
```
18
+
19
+
This should help you next time you get messed with YAML formatting.
20
+
21
+
* Gherkin improvements:
22
+
* multiple step definitions per method allowed (Fixes [#3670](https://github.com/Codeception/Codeception/issues/3670))
23
+
24
+
```php
25
+
/**
26
+
* **[When](https://github.com/When)** I have no orders
27
+
* **[Then](https://github.com/Then)** I have empty bucket
28
+
*/
29
+
public function haveEmptyBucket()
30
+
```
31
+
32
+
* regex validation for Gherkin steps; throws exception if invalid regex passed. Fixes [#3676](https://github.com/Codeception/Codeception/issues/3676)
33
+
* currency chars supported in placeholders:
34
+
35
+
$,€,£ and other signs can be used before or after a number inside Gherkin scenario. This char will be ignored inside a PHP variable, so you receive only number.
36
+
37
+
```gherkin
38
+
When I have 100$ => $num === 100
39
+
And I have $100 => $num === 100
40
+
```
41
+
* escaped strings can now be passed into placeholders. Fixes [#3676](https://github.com/Codeception/Codeception/issues/3676).
42
+
43
+
* Codeception is tested with latest verision of HHVM
44
+
* Extensions loader refactored:
45
+
* Extensions can be **enabled for suite** in suite config.
46
+
* Extensions can be loaded per suite and per environment.
47
+
* Extensions configs can be done inside `enabled` section (as it is for modules):
48
+
49
+
```yaml
50
+
extensions:
51
+
enabled:
52
+
Codeception\Extension\Recorder:
53
+
delete_successful: false
54
+
```
55
+
* **Added dataprovider to Cest** format by **[endo](https://github.com/endo)**. See [updated documentation](http://codeception.com/docs/07-AdvancedUsage#Examples).
56
+
* Params loader refactored. Using `vlucas/phpdotenv` to parse .env files. Please install it if you don't have it yet.
57
+
* Improved `generate:suite` command to generate actor file for suite.
58
+
* HTML reporter: snapshot and screenshots paths made relative to make them accessible on CI. Fixes [#3702](https://github.com/Codeception/Codeception/issues/3702)
59
+
* **[WebDriver]** added `protocol` and `path` config options by **[sven](https://github.com/sven)**-carstens-udg. See [#3717](https://github.com/Codeception/Codeception/issues/3717)
60
+
* [PhpBrowser][Frameworks] Honour `<base href="">` meta tag by **[Naktibalda](https://github.com/Naktibalda)**. See [#3764](https://github.com/Codeception/Codeception/issues/3764)
61
+
* **[Yii2]** Removed mockAssetManager by **[githubjeka](https://github.com/githubjeka)**
62
+
* **[Yii2]** Added procesing for native url formats of Yii2 [#3725](https://github.com/Codeception/Codeception/issues/3725) by **[githubjeka](https://github.com/githubjeka)**
63
+
* **[Yii2]** Fixed unintentional DB connection drop during exception logging, [#3696](https://github.com/Codeception/Codeception/issues/3696) by **[ivokund](https://github.com/ivokund)**
64
+
* **[Yii2]** Fixed calling `_fixtures()` method of Cest class. See [#3655](https://github.com/Codeception/Codeception/issues/3655), fixes [#3612](https://github.com/Codeception/Codeception/issues/3612) by **[primipilus](https://github.com/primipilus)**
65
+
* **[Db]** Fixed `removeInserted` for Sqlite by **[Naktibalda](https://github.com/Naktibalda)**. Fixes [#3680](https://github.com/Codeception/Codeception/issues/3680)
66
+
* Allows to get groups from scenario by `$scenario->getGroups()`. By **[frantzen](https://github.com/frantzen)**. See [#3675](https://github.com/Codeception/Codeception/issues/3675)
67
+
* Fixed [#3225](https://github.com/Codeception/Codeception/issues/3225): incorrect steps shown for multiple canXXX conditional assertion failures. By **[Mitrichius](https://github.com/Mitrichius)**
68
+
* **[SOAP]** Force string for debugSection output by **[Noles](https://github.com/Noles)**. Fixes [#3690](https://github.com/Codeception/Codeception/issues/3690)
69
+
* Fixed [#3562](https://github.com/Codeception/Codeception/issues/3562) group files with exact test not working with `@example` on Windows by **[Naktibalda](https://github.com/Naktibalda)**.
70
+
* **[Laravel5]** Added `vendor_dir` option. See [#3775](https://github.com/Codeception/Codeception/issues/3775). By **[AdrianSkierniewski](https://github.com/AdrianSkierniewski)**
71
+
* **[Laravel5]** Fixed error where custom service container bindings were not available on the first request. See [#3728](https://github.com/Codeception/Codeception/issues/3728). By **[janhenkgerritsen](https://github.com/janhenkgerritsen)**
72
+
* **[Lumen]** Fixed error where a non-existing exception class was thrown. See [#3729](https://github.com/Codeception/Codeception/issues/3729). By **[janhenkgerritsen](https://github.com/janhenkgerritsen)**
73
+
* **[Phalcon]** Added `services` part which can be used to `grabServiceFromContainer` and `addServiceToContainer` when conflicting module is used. By **[sergeyklay](https://github.com/sergeyklay)**
74
+
* **[Phalcon]** **Refactored**. Moved in-memory session adapter to the separated namespace. By **[sergeyklay](https://github.com/sergeyklay)**
75
+
* **[Phalcon]** Fixed overwriting server parameters on requests. By **[sergeyklay](https://github.com/sergeyklay)**
76
+
* **[Asserts]** `assertCount` method added by **[disc](https://github.com/disc)**
77
+
* Documentation improvements by **[CJDennis](https://github.com/CJDennis)**
78
+
10
79
#### 2.2.6 (October 2016)
11
80
12
81
* Ability to update config on run with `--override` (`-o`) option. Usage Examples:
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.
8
+
The idea behind testing is not new. You can't sleep well if you are not confident
9
+
that your last commit didn't take down the whole application.
9
10
Having your application covered with tests gives you more trust in the stability of your application. That's all.
10
11
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, but with tests you can cover the most important parts of your app and at least be sure they work as predicted.
12
+
In most cases tests don't guarantee that the application works 100% as it is supposed to.
13
+
You can't predict all possible scenarios and exceptional situations for complex apps,
14
+
but with tests you can cover the most important parts of your app and at least be sure they work as predicted.
12
15
13
-
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.
16
+
There are plenty of ways to test your application.
17
+
The most popular paradigm is [Unit Testing](http://en.wikipedia.org/wiki/Unit_testing).
18
+
For web applications, testing just the controller and / or the model doesn't prove that your application is working.
19
+
To test the behavior of your application as a whole, you should write functional or acceptance tests.
14
20
15
-
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.
21
+
Codeception supports these testing types.
22
+
Out of the box you have tools for writing unit, functional, and acceptance tests in a unified framework.
16
23
17
24
Let's review the listed testing paradigms in reverse order.
18
25
19
26
### Acceptance Tests
20
27
21
-
How does your client, manager, or tester, or any other non-technical person, know your website is working? By opening the browser, accessing a site, clicking on links, filling in the forms, and actually seeing the content on a web page. That person has no idea of the framework, database, web-server, or programming language you use or why the application did not behave as expected.
28
+
How does your client, manager, tester, or any other non-technical person know your website is working?
29
+
By opening the browser, accessing a site, clicking on links, filling in the forms,
30
+
and actually seeing the content on a web page. They has no idea of the framework, database, web-server,
31
+
or programming language you use or why the application did not behave as expected.
22
32
23
-
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.
33
+
Acceptance tests can cover standard but complex scenarios from a user's perspective.
34
+
With acceptance tests, you can be confident that users, following all the defined scenarios, won't get errors.
24
35
25
-
Please, note that **any website** can be covered with acceptance tests. Even if you use a very custom CMS or framework.
36
+
Please note that **any website** can be covered with acceptance tests, even if you use a very custom CMS or framework.
26
37
27
38
#### Sample acceptance test
28
39
@@ -40,24 +51,28 @@ $I->see('Thank you for Signing Up!');
40
51
#### Pros
41
52
42
53
* can be run on any website
43
-
* can test javascript and ajax requests
54
+
* can test JavaScript and AJAX requests
44
55
* can be shown to your clients and managers
45
56
* most stable in support: less affected by changes in source code or technologies
46
57
47
58
#### Cons
48
59
* the slowest: requires running browser and database repopulation
49
60
* fewer checks can lead to false-positive results
50
-
* yep, they are really slow
51
-
* not stable in execution: rendering and javascript issues can lead to unpredictable results
61
+
* not stable in execution: rendering and JavaScript issues can lead to unpredictable results
52
62
53
63
54
64
### Functional Tests
55
65
56
-
What if we could check our application without running it on a server? This way we could see detailed exceptions on errors, have tests running faster, and check the database for values we expect. That's what functional tests are for.
66
+
What if we could check our application without running it on a server?
67
+
That way we could see detailed exceptions on errors, have our tests run faster,
68
+
and check the database against predictable and expected results. That's what functional tests are for.
57
69
58
-
For functional tests you emulate a web request (`$_GET` and `$_POST` variables) and send it into your application which returns HTML response. Inside a test you can make assertions about the response, and you can check if the data was successfully stored into the database.
70
+
For functional tests, you emulate a web request (`$_GET` and `$_POST` variables)
71
+
which returns the HTML response. Inside a test, you can make assertions about the response,
72
+
and you can check if the data was successfully stored in the database.
59
73
60
-
For functional tests your application should be prepared to be run in a test environment. Codeception provides connectors to several popular PHP frameworks, or you could write your own.
74
+
For functional tests, your application needs to be structured in order to run in a test environment.
75
+
Codeception provides connectors to several popular PHP frameworks. You can also write your own.
* by emulating the browser you might get more false-positive results
88
103
* requires a framework
89
104
90
105
### Unit Tests
91
106
92
-
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 if it was not covered by functional or acceptance tests. This also proves that you produced stable and testable code.
107
+
Testing pieces of code before coupling them together is highly important as well. This way,
108
+
you can be sure that some deeply hidden feature still works, even if it was not covered by functional or acceptance tests.
109
+
This also shows care in producing stable and testable code.
93
110
94
-
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, but Codeception provides some well built tools to make your unit tests simpler and cleaner.
111
+
Codeception is created on top of [PHPUnit](http://www.phpunit.de/). If you have experience writing unit tests with PHPUnit
112
+
you can continue doing so. Codeception has no problem executing standard PHPUnit tests,
113
+
but, additionally, Codeception provides some well-built tools to make your unit tests simpler and cleaner.
95
114
96
-
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 the requirements. The better you understand the testing scenario, the faster you can update it for new behavior.
115
+
Requirements and code can change rapidly,
116
+
and unit tests should be updated every time to fit the requirements.
117
+
The better you understand the testing scenario, the faster you can update it for new behavior.
97
118
98
119
#### Sample integration test
99
120
@@ -114,10 +135,11 @@ function testSavingUser()
114
135
115
136
#### Pros
116
137
117
-
* fastest (well, in the current example, you still need database repopulation)
138
+
* fastest (well, in the current example, you still need database repopulation because it's an integration test,
139
+
not a pure unit test)
118
140
* can cover rarely used features
119
-
* can test stability of application core
120
-
* you can only be considered a good developer if you write them :)
141
+
* can test the stability of the application core
142
+
* fundamental for any developer
121
143
122
144
#### Cons
123
145
@@ -126,9 +148,13 @@ function testSavingUser()
126
148
127
149
## Conclusion
128
150
129
-
Despite the wide popularity of TDD, not all PHP developers ever write automated tests for their applications. The Codeception framework was developed to make testing actually fun. It allows writing unit, functional, integration, and acceptance tests, in one style.
151
+
Despite the wide popularity of *TDD* (Test Driven Development), some PHP developers never write automated tests for their applications mostly because they think it's hard, slow or boring..
152
+
The Codeception framework was developed to actually make testing fun.
153
+
It allows writing unit, functional, integration, and acceptance tests, in a single, coherent style.
130
154
131
-
It could be called a BDD framework. All Codeception tests are written in a descriptive manner. Just by looking at 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.
155
+
It can be called a *BDD* (Behavior Driven Development) framework. All Codeception tests are written in a descriptive manner.
156
+
Just by looking at the test body, you can clearly understand what is being tested and how it is performed.
157
+
Even complex tests with many assertions are written in a simple PHP Domain-Specific Language (*DSL*).
0 commit comments