Skip to content

Commit 3b19f56

Browse files
Adding redirect to Symfony Module
See Codeception/module-symfony#98 (comment) I'm not sure if `<meta>` really works here, but let's see :-)
1 parent f3eec45 commit 3b19f56

File tree

1 file changed

+2
-156
lines changed

1 file changed

+2
-156
lines changed

for/symfony.md

Lines changed: 2 additions & 156 deletions
Original file line numberDiff line numberDiff line change
@@ -1,169 +1,15 @@
1+
<meta http-equiv="refresh" content="0;url=https://codeception.com/docs/modules/Symfony">
12
---
23
layout: page
34
title: Codeception for Symfony
45
hero: symfony_hero.html
56
sidebar: |
67

7-
## Features
8-
9-
* Access Symfony services through the dependency injection container: `$I->grabService(...)`
10-
* Use Doctrine to test against the database: `$I->seeInRepository(...)`
11-
* Assert that emails would have been sent: `$I->seeEmailIsSent()`
12-
* Tests are wrapped into Doctrine transaction to speed them up.
13-
* Symfony Router can be cached between requests to speed up testing.
14-
15-
## Reference
16-
17-
* [Symfony Module](/docs/modules/Symfony)
18-
* [Doctrine2 Module](http://codeception.com/docs/modules/Doctrine2)
19-
* [Demo Application](https://github.com/Codeception/symfony-demo)
20-
218
---
229

23-
## Install
24-
25-
Install Codeception and required modules via Composer:
26-
27-
```bash
28-
composer require codeception/codeception codeception/module-symfony codeception/module-doctrine2 codeception/module-asserts codeception/module-rest codeception/module-webdriver --dev
29-
```
30-
31-
## Setup
32-
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`.
35-
36-
### Acceptance Testing
37-
38-
Sample configuration of `tests/acceptance.suite.yml`:
39-
40-
```yaml
41-
class_name: AcceptanceTester
42-
modules:
43-
enabled:
44-
- WebDriver:
45-
url: 'https://localhost/' # put your local url
46-
browser: chrome
47-
- \Helper\Acceptance
48-
```
49-
50-
Browser can be specified as `chrome`, `firefox`, or others.
51-
52-
To create a sample test called, run:
53-
54-
```
55-
vendor/bin/codecept g:cest acceptance UserCest
56-
```
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`.
59-
60-
<div class="alert alert-warning">
61-
<span class="glyphicon glyphicon-info-sign" aria-hidden="true"></span>
62-
Continue to <a href="http://codeception.com/docs/03-AcceptanceTests">Acceptance Testing Guide &raquo;</a>
63-
</div>
64-
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
66-
67-
```
68-
vendor/bin/codecept run acceptance
69-
```
70-
71-
### BDD
72-
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.
74-
75-
```
76-
ln -s $PWD/features tests/acceptance
77-
```
78-
79-
Codeception allows to combine tests written in different formats. If you are about to write a regression test it probably should not be described as a product's feature. That's why feature-files are a subset of all acceptance tests, and they are stored in subfolder of `tests/acceptance`.
80-
81-
There are no standard Gherkin steps built in. By writing your feature files you can get code snippets which should be added to `AcceptanceTester` class.
82-
83-
```
84-
vendor/bin/codecept gherkin:snippets
85-
```
86-
8710
<div class="alert alert-warning">
88-
<span class="glyphicon glyphicon-info-sign" aria-hidden="true"></span>
89-
Continue to <a href="http://codeception.com/docs/07-BDD">Behavior Driven Development Guide &raquo;</a>
11+
See <a href="https://codeception.com/docs/modules/Symfony">Symfony Module</a>
9012
</div>
9113

92-
## Functional Testing
93-
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.
95-
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:
97-
98-
```yaml
99-
class_name: FunctionalTester
100-
modules:
101-
enabled:
102-
- Symfony:
103-
app_path: 'src'
104-
environment: 'test'
105-
- Doctrine2:
106-
depends: Symfony
107-
- \Helper\Functional
108-
```
109-
110-
<div class="alert alert-warning">
111-
<span class="glyphicon glyphicon-info-sign" aria-hidden="true"></span>
112-
Learn more about starting with Symfony in <a href="http://codeception.com/09-04-2015/using-codeception-for-symfony-projects.html">our blogpost &raquo;</a>
113-
</div>
114-
115-
<div class="alert alert-warning">
116-
<span class="glyphicon glyphicon-info-sign" aria-hidden="true"></span>
117-
Continue to <a href="http://codeception.com/docs/04-FunctionalTests">Functional Testing Guide &raquo;</a>
118-
</div>
119-
120-
### API Tests
121-
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:
123-
124-
```
125-
vendor/bin/codecept g:suite api
126-
```
127-
128-
You will need to enable `REST`, `Symfony` and `Doctrine2` module in `tests/api.suite.yml`:
129-
130-
```yaml
131-
class_name: ApiTester
132-
modules:
133-
enabled:
134-
- Symfony:
135-
app_path: 'src'
136-
environment: 'test'
137-
- REST:
138-
url: /v1
139-
depends: Symfony
140-
- Doctrine2:
141-
depends: Symfony
142-
- \Helper\Api
143-
```
144-
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`.
146-
147-
148-
<div class="alert alert-warning">
149-
<span class="glyphicon glyphicon-info-sign" aria-hidden="true"></span>
150-
Continue to <a href="http://codeception.com/docs/10-APITesting#REST-API">REST API Testing Guide &raquo;</a>.
151-
</div>
152-
153-
154-
### Unit Testing
155-
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:
157-
158-
```
159-
vendor/bin/codecept g:test unit Foo
160-
```
161-
162-
Actions of Symfony and Doctrine2 modules will be accessible from `$this->tester` inside a test of `Codeception\Test\Unit`.
163-
164-
<div class="alert alert-warning">
165-
<span class="glyphicon glyphicon-info-sign" aria-hidden="true"></span>
166-
Continue to <a href="http://codeception.com/docs/05-UnitTests">Unit Testing Guide &raquo;</a>.
167-
</div>
16814

16915
[Edit this page on GitHub](https://github.com/Codeception/codeception.github.com/blob/master/for/symfony.md)

0 commit comments

Comments
 (0)