Skip to content

Deleting "Project setup" #163

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 18, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 18 additions & 52 deletions for/symfony.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,71 +30,47 @@ composer require codeception/codeception --dev

## Setup

From Symfony 4 onwards there will be a top-level `tests` directory, instead of a separate `Tests` directory in each bundle.
It is recommended to place unit, functional, and acceptance test files
into `tests`.

### Project Setup

Codeception should be installed globally for a project. To start, please run

```
php bin/codecept bootstrap --empty
```

This will create `codeception.yml` and the `tests` directory. There are no test suites inside `tests` yet.
For Symfony >= 4 there is a top-level `tests` directory, instead of a separate `Tests` directory in each bundle.
It is recommended to place unit, functional, and acceptance test files into `tests`.

### Acceptance Testing

For UI testing you will have to create first suite for acceptance tests:

```
php bin/codecept g:suite acceptance
```

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.
Sample configuration of `tests/acceptance.suite.yml`:

```yaml
class_name: AcceptanceTester
modules:
enabled:
- WebDriver:
url: 'https://localhost/' # put your local url
browser: firefox
browser: chrome
- \Helper\Acceptance
```

Browser can be specified as `firefox`, `chrome`, `phantomjs`, or others.

Acceptance tests should be described in Cest format. Run code generator

```
php bin/codecept g:cest acceptance UserCest
```

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`.
Browser can be specified as `chrome`, `firefox`, `phantomjs`, or others.

To generate method stubs for `AcceptanceTester`.
To create a sample test called, run:

```
php bin/codecept build
vendor/bin/codecept g:cest acceptance UserCest
```

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`.

<div class="alert alert-warning">
<span class="glyphicon glyphicon-info-sign" aria-hidden="true"></span>
Continue to <a href="http://codeception.com/docs/03-AcceptanceTests">Acceptance Testing Guide &raquo;</a>
</div>

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
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

```
php bin/codecept run acceptance
vendor/bin/codecept run acceptance
```

### BDD

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.
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.

```
ln -s $PWD/features tests/acceptance
Expand All @@ -105,7 +81,7 @@ Codeception allows to combine tests written in different formats. If are about t
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.

```
php bin/codecept gherkin:snippets
vendor/bin/codecept gherkin:snippets
```

<div class="alert alert-warning">
Expand All @@ -115,13 +91,9 @@ php bin/codecept gherkin:snippets

## Functional Testing

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:
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.

```
php bin/codecept g:suite functional
```

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:
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:

```yaml
class_name: FunctionalTester
Expand Down Expand Up @@ -150,7 +122,7 @@ modules:
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:

```
php bin/codecept g:suite api
vendor/bin/codecept g:suite api
```

You will need to enable `REST`, `Symfony` and `Doctrine` module in `tests/api.suite.yml`:
Expand All @@ -170,7 +142,7 @@ modules:
- \Helper\Api
```

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.
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`.


<div class="alert alert-warning">
Expand All @@ -181,16 +153,10 @@ Symfony module actions like `amOnPage` or `see` should not be available for test

### Unit Testing

Create a unit test suite with:

```
php bin/codecept g:suite unit
```

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:
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:

```
php bin/codecept g:test unit Foo
vendor/bin/codecept g:test unit Foo
```

Actions of Symfony and Doctrine2 modules will be accessible from `$this->tester` inside a test of `Codeception\Test\Unit`.
Expand Down
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy