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
* Deleting "Project setup"
...since this is already included in `composer require codeception/codeception --dev`
* Deleting more unnecessary stuff...
...and updating to `vendor/bin/codecept`
From Symfony 4 onwards there will be a top-level `tests` directory, instead of a separate `Tests` directory in each bundle.
34
-
It is recommended to place unit, functional, and acceptance test files
35
-
into `tests`.
36
-
37
-
### Project Setup
38
-
39
-
Codeception should be installed globally for a project. To start, please run
40
-
41
-
```
42
-
php bin/codecept bootstrap --empty
43
-
```
44
-
45
-
This will create `codeception.yml` and the `tests` directory. There are no test suites inside `tests` yet.
33
+
For Symfony >= 4 there is a top-level `tests` directory, instead of a separate `Tests` directory in each bundle.
34
+
It is recommended to place unit, functional, and acceptance test files into `tests`.
46
35
47
36
### Acceptance Testing
48
37
49
-
For UI testing you will have to create first suite for acceptance tests:
50
-
51
-
```
52
-
php bin/codecept g:suite acceptance
53
-
```
54
-
55
-
This will create `acceptance.suite.yml` and `acceptance` folder inside `tests`. Acceptance tests should be configured to work with Selenium WebDriver to test application inside a real browser.
38
+
Sample configuration of `tests/acceptance.suite.yml`:
56
39
57
40
```yaml
58
41
class_name: AcceptanceTester
59
42
modules:
60
43
enabled:
61
44
- WebDriver:
62
45
url: 'https://localhost/'# put your local url
63
-
browser: firefox
46
+
browser: chrome
64
47
- \Helper\Acceptance
65
48
```
66
49
67
-
Browser can be specified as `firefox`, `chrome`, `phantomjs`, or others.
68
-
69
-
Acceptance tests should be described in Cest format. Run code generator
70
-
71
-
```
72
-
php bin/codecept g:cest acceptance UserCest
73
-
```
74
-
75
-
to generate very first test `tests/acceptance/UserCest.php`. Each method of a class (except `_before` and `_after`) is a test. Tests use `$I` object (instance of `AcceptanceTester` class) to perform actions on a webpage. Methods of `AcceptanceTester` are proxified to corresponding modules, which in current case is `WebDriver`.
50
+
Browser can be specified as `chrome`, `firefox`, `phantomjs`, or others.
76
51
77
-
To generate method stubs for `AcceptanceTester`.
52
+
To create a sample test called, run:
78
53
79
54
```
80
-
php bin/codecept build
55
+
vendor/bin/codecept g:cest acceptance UserCest
81
56
```
82
57
58
+
This will create the file `tests/acceptance/UserCest.php`. Each method of a class (except `_before` and `_after`) is a test. Tests use `$I` object (instance of `AcceptanceTester` class) to perform actions on a webpage. Methods of `AcceptanceTester` are proxified to corresponding modules, which in current case is `WebDriver`.
Continue to <a href="http://codeception.com/docs/03-AcceptanceTests">Acceptance Testing Guide »</a>
87
63
</div>
88
64
89
-
To run the tests you will need firefox browser, [selenium server running](http://codeception.com/docs/modules/WebDriver#Selenium). If this requirements met acceptance tests can be executed as
65
+
To run the tests you will need chrome browser, [selenium server running](http://codeception.com/docs/modules/WebDriver#Selenium). If this requirements met acceptance tests can be executed as
90
66
91
67
```
92
-
php bin/codecept run acceptance
68
+
vendor/bin/codecept run acceptance
93
69
```
94
70
95
71
### BDD
96
72
97
-
If you prefer to describe application with feature files, Codeception can turn them to acceptance tests. It is recommended to store feature files in `features` directory (like it does Behat) but symlinking it to `tests/acceptance/features` so they can be treated as tests too.
73
+
If you prefer to describe application with feature files, Codeception can turn them to acceptance tests. It is recommended to store feature files in `features` directory (like Behat does it) but symlinking it to `tests/acceptance/features` so they can be treated as tests too.
98
74
99
75
```
100
76
ln -s $PWD/features tests/acceptance
@@ -105,7 +81,7 @@ Codeception allows to combine tests written in different formats. If are about t
105
81
There is no standard Gherkin steps built in. By writing your feature files you can get code snippets which should be added to `AcceptanceTester` class.
There is no need to use `WebTestCase` to write functional tests. Symfony functional tests are written in the same manner as acceptance tests but are executed inside a framework. Codeception has the [Symfony Module](http://codeception.com/docs/modules/Symfony) for it. To create a functional test suite, run:
94
+
There is no need to use `WebTestCase` to write functional tests. Symfony functional tests are written in the same manner as acceptance tests but are executed inside the framework. Codeception has the [Symfony Module](http://codeception.com/docs/modules/Symfony) for it.
119
95
120
-
```
121
-
php bin/codecept g:suite functional
122
-
```
123
-
124
-
Functional tests are written in the same manner as acceptance tests. They also use scenario and `$I` actor object. The only difference is how they are executed. To run tests as Symfony test you should enable corresponding module in functional suite configuration file `tests/functional.suite.yml`. Probably you want Doctrine to be included as well. Then you should use this configuration:
96
+
Functional tests also use scenario and `$I` actor object. The only difference is how they are executed. To run tests as Symfony test you should enable the corresponding module in functional suite configuration file `tests/functional.suite.yml`. Probably you want Doctrine to be included as well. Then you should use this configuration:
125
97
126
98
```yaml
127
99
class_name: FunctionalTester
@@ -150,7 +122,7 @@ modules:
150
122
API Tests are done at functional testing level but instead of testing HTML responses on user actions, they test requests and responses via protocols like REST or SOAP. To create api tests, you should create a suite for them:
151
123
152
124
```
153
-
php bin/codecept g:suite api
125
+
vendor/bin/codecept g:suite api
154
126
```
155
127
156
128
You will need to enable `REST`, `Symfony` and `Doctrine` module in `tests/api.suite.yml`:
@@ -170,7 +142,7 @@ modules:
170
142
- \Helper\Api
171
143
```
172
144
173
-
Symfony module actions like `amOnPage` or `see` should not be available for testing API. This why Symfony module is not enabled but declared with `depends` for REST module. But Symfony module should be configured to load Kernel class from app_path.
145
+
Symfony module actions like `amOnPage` or `see` should not be available for testing API. This is why Symfony module is not enabled but declared with `depends` for REST module. But Symfony module should be configured to load Kernel class from `app_path`.
174
146
175
147
176
148
<div class="alert alert-warning">
@@ -181,16 +153,10 @@ Symfony module actions like `amOnPage` or `see` should not be available for test
181
153
182
154
### Unit Testing
183
155
184
-
Create a unit test suite with:
185
-
186
-
```
187
-
php bin/codecept g:suite unit
188
-
```
189
-
190
-
Codeception is powered by PHPUnit so unit and integration test work in a similar manner. To genereate a plain PHPUnit test for `Foo` class, run:
156
+
Codeception is powered by PHPUnit so unit and integration tests work in a similar manner. To genereate a plain PHPUnit test for class `Foo`, run:
191
157
192
158
```
193
-
php bin/codecept g:test unit Foo
159
+
vendor/bin/codecept g:test unit Foo
194
160
```
195
161
196
162
Actions of Symfony and Doctrine2 modules will be accessible from `$this->tester` inside a test of `Codeception\Test\Unit`.
0 commit comments