diff --git a/_includes/extensions.md b/_includes/extensions.md index eb280dea..ee16b18e 100644 --- a/_includes/extensions.md +++ b/_includes/extensions.md @@ -75,7 +75,7 @@ The screenshots are saved to `tests/_output/record_*` directories, open `index.h #### Installation -Add this to the list of enabled extensions in `codeception.yml` or `acceptance.suite.yml`: +Add this to the list of enabled extensions in `codeception.yml` or `Acceptance.suite.yml`: ``` yaml extensions: @@ -136,7 +136,7 @@ Dependent processes run sequentially one by one. Can be configured in suite config: ```yaml -# acceptance.suite.yml +# Acceptance.suite.yml extensions: enabled: - Codeception\Extension\RunBefore: @@ -193,7 +193,7 @@ Can be used to start/stop selenium server, chromedriver, mailcatcher, etc. Can be configured in suite config: ```yaml -# acceptance.suite.yml +# Acceptance.suite.yml extensions: enabled: - Codeception\Extension\RunProcess: @@ -203,7 +203,7 @@ extensions: Multiple parameters can be passed as array: ```yaml -# acceptance.suite.yml +# Acceptance.suite.yml extensions: enabled: diff --git a/docs/APITesting.md b/docs/APITesting.md index 002e4999..dc1950dc 100644 --- a/docs/APITesting.md +++ b/docs/APITesting.md @@ -9,10 +9,10 @@ title: API Testing - Codeception Docs The same way we tested a web site, Codeception allows you to test web services. They are very hard to test manually, so it's a really good idea to automate web service testing. We have SOAP and REST as standards, which are represented in corresponding modules, which we will cover in this chapter. -You should start by creating a new test suite, (which was not provided by the `bootstrap` command). We recommend calling it **api** and using the `ApiTester` class for it. +You should start by creating a new test suite, (which was not provided by the `bootstrap` command). We recommend calling it **Api** and using the `ApiTester` class for it. ```bash -php vendor/bin/codecept generate:suite api +php vendor/bin/codecept generate:suite Api ``` We will put all the api tests there. @@ -23,7 +23,7 @@ We will put all the api tests there. The REST web service is accessed via HTTP with standard methods: `GET`, `POST`, `PUT`, `DELETE`. They allow users to receive and manipulate entities from the service. Accessing a WebService requires an HTTP client, so for using it you need the module `PhpBrowser` or one of framework modules set up. For example, we can use the `Symfony` module for Symfony2 applications in order to ignore web server and test web service internally. -Configure modules in `api.suite.yml`: +Configure modules in `Api.suite.yml`: ```yaml actor: ApiTester @@ -60,7 +60,7 @@ modules: Once we have configured our new testing suite, we can create the first sample test: ```bash -php vendor/bin/codecept generate:cest api CreateUser +php vendor/bin/codecept generate:cest Api CreateUser ``` It will be called `CreateUserCest.php`. @@ -379,7 +379,7 @@ class Api extends \Codeception\Module { ## Conclusion -Codeception has two modules that will help you to test various web services. They need a new `api` suite to be created. Remember, you are not limited to test only response body. By including `Db` module you may check if a user has been created after the `CreateUser` call. You can improve testing scenarios by using REST or SOAP responses in your helper methods. +Codeception has two modules that will help you to test various web services. They need a new `Api` suite to be created. Remember, you are not limited to test only response body. By including `Db` module you may check if a user has been created after the `CreateUser` call. You can improve testing scenarios by using REST or SOAP responses in your helper methods.
Improve this guide
diff --git a/docs/AcceptanceTests.md b/docs/AcceptanceTests.md index 67cc3f68..0ccec68a 100644 --- a/docs/AcceptanceTests.md +++ b/docs/AcceptanceTests.md @@ -57,7 +57,7 @@ Common PhpBrowser drawbacks: We need to specify the `url` parameter in the acceptance suite config: ```yaml -# acceptance.suite.yml +# Acceptance.suite.yml actor: AcceptanceTester modules: enabled: @@ -68,10 +68,10 @@ modules: We should start by creating a test with the next command: ``` -php vendor/bin/codecept g:cest acceptance Signin +php vendor/bin/codecept g:cest Acceptance Signin ``` -It will be placed into `tests/acceptance` directory. +It will be placed into `tests/Acceptance` directory. ```php class SigninCest @@ -268,10 +268,10 @@ Each failed assertion will be shown in the test results, but it won't stop the t Conditional assertions are disabled in bootstrap setup. To enable them you should add corresponding step decorators to suite config: -> If you started project as `codecept init acceptance` they should be already enabled in config +> If you started project as `codecept init Acceptance` they should be already enabled in config ```yaml -# in acceptance.suite.yml +# in Acceptance.suite.yml # or in codeception.yml inside suites section step_decorators: - \Codeception\Step\ConditionalAssertion @@ -390,7 +390,7 @@ Now, you are ready to run WebDriver tests using Codeception. To execute a test in a browser you need to change the suite configuration to use **WebDriver** module. -Modify your `acceptance.suite.yml` file: +Modify your `Acceptance.suite.yml` file: ```yaml actor: AcceptanceTester @@ -503,10 +503,10 @@ $I->retry(4, 400); Retries are disabled by default. To enable them you should add retry step decorators to suite config: -> If you started project as `codecept init acceptance` they should be already enabled in config +> If you started project as `codecept init Acceptance` they should be already enabled in config ```yaml -# in acceptance.suite.yml +# in Acceptance.suite.yml # or in codeception.yml inside suites section step_decorators: - \Codeception\Step\Retry @@ -578,10 +578,10 @@ if ($I->tryToSeeElement('.alert')) { A/B testing is disabled by default. To enable it you should add corresponding step decorators to suite config: -> If you started project as `codecept init acceptance` in Codeception >= 3.0 they should be already enabled in config +> If you started project as `codecept init Acceptance` in Codeception >= 3.0 they should be already enabled in config ```yaml -# in acceptance.suite.yml +# in Acceptance.suite.yml # or in codeception.yml inside suites section step_decorators: - \Codeception\Step\TryTo diff --git a/docs/AdvancedUsage.md b/docs/AdvancedUsage.md index 13bcc126..fe6397de 100644 --- a/docs/AdvancedUsage.md +++ b/docs/AdvancedUsage.md @@ -192,7 +192,7 @@ public function testNotReadyToday() There are several ways to execute a bunch of tests. You can run tests from a specific directory: ``` -php vendor/bin/codecept run tests/acceptance/admin +php vendor/bin/codecept run tests/Acceptance/admin ``` You can execute one (or several) specific groups of tests: diff --git a/docs/BDD.md b/docs/BDD.md index 94b2fd18..1c0cc867 100644 --- a/docs/BDD.md +++ b/docs/BDD.md @@ -88,7 +88,7 @@ Feature file is written in Gherkin format. Codeception can generate a feature fi We will assume that we will use scenarios in feature files for acceptance tests, so feature files to be placed in `acceptance` suite directory: ```bash -php vendor/bin/codecept g:feature acceptance checkout +php vendor/bin/codecept g:feature Acceptance checkout ``` Generated template will look like this: @@ -151,13 +151,13 @@ And in the end we are verifying our expectation using **Then** keyword. The acti We can test this scenario by executing it in dry-run mode. In this mode test won't be executed (actually, we didn't define any step for it, so it won't be executed in any case). ```bash -php vendor/bin/codecept dry-run acceptance checkout.feature +php vendor/bin/codecept dry-run Acceptance checkout.feature ``` ```bash checkout: order several products Signature: checkout:order several products -Test: tests/acceptance/checkout.feature:order several products +Test: tests/Acceptance/checkout.feature:order several products Scenario -- In order to buy product As a customer @@ -181,7 +181,7 @@ Besides the scenario steps listed we got the notification that our steps are not We can define them easily by executing `gherkin:snippets` command for the given suite: ```bash -php vendor/bin/codecept gherkin:snippets acceptance +php vendor/bin/codecept gherkin:snippets Acceptance ``` This will produce code templates for all undefined steps in all feature files of this suite. @@ -551,7 +551,7 @@ While Behat is a great tool for Behavior Driven Development, you still may prefe If you decided to run your features with Codeception, we recommend to start with symlinking your `features` directory into one of the test suites: ```bash -ln -s $PWD/features tests/acceptance +ln -s $PWD/features tests/Acceptance ``` Then you will need to implement all step definitions. Run `gherkin:snippets` to generate stubs for them. diff --git a/docs/Codecoverage.md b/docs/Codecoverage.md index c684c4f7..d164cfd1 100644 --- a/docs/Codecoverage.md +++ b/docs/Codecoverage.md @@ -153,7 +153,7 @@ coverage: ### Remote Server But if you run tests on different server (or your webserver doesn't use code from current directory) a single option `remote` should be added to config. -For example, let's turn on remote coverage for acceptance suite in `acceptance.suite.yml`: +For example, let's turn on remote coverage for acceptance suite in `Acceptance.suite.yml`: ```yaml diff --git a/docs/ContinuousIntegration.md b/docs/ContinuousIntegration.md index a7c78150..a0fdb7a0 100644 --- a/docs/ContinuousIntegration.md +++ b/docs/ContinuousIntegration.md @@ -181,7 +181,7 @@ before_script: # Test test: script: - - vendor/bin/codecept run acceptance --xml --html + - vendor/bin/codecept run Acceptance --xml --html artifacts: when: always expire_in: 1 week diff --git a/docs/Customization.md b/docs/Customization.md index 5a463213..591a0319 100644 --- a/docs/Customization.md +++ b/docs/Customization.md @@ -35,10 +35,10 @@ and you want to get a single report in JUnit and HTML format. The code coverage If you want to run a specific suite from the application you can execute: ```bash -php vendor/bin/codecept run unit -c frontend +php vendor/bin/codecept run Unit -c frontend ``` -Where `unit` is the name of suite and the `-c` option specifies the path to the `codeception.yml` configuration file to use. +Where `Unit` is the name of suite and the `-c` option specifies the path to the `codeception.yml` configuration file to use. In this example we will assume that there is `frontend/codeception.yml` configuration file and that we will execute the unit tests for only that app. @@ -199,7 +199,7 @@ extensions: ``` -Extensions can also be enabled per suite inside suite configs (like `acceptance.suite.yml`) and for a specific environment. +Extensions can also be enabled per suite inside suite configs (like `Acceptance.suite.yml`) and for a specific environment. To enable extension dynamically, execute the `run` command with `--ext` option. Provide a class name as a parameter: @@ -371,7 +371,7 @@ You can pass the `-c` option to any Codeception command (except `bootstrap`), to ``` php vendor/bin/codecept run -c ~/projects/ecommerce/ php vendor/bin/codecept run -c ~/projects/drupal -php vendor/bin/codecept generate:cest acceptance CreateArticle -c ~/projects/drupal/ +php vendor/bin/codecept generate:cest Acceptance CreateArticle -c ~/projects/drupal/ ``` @@ -393,19 +393,19 @@ Tests for groups can be specified as an array of file names or directories conta ```yaml groups: # add 2 tests to db group - db: [tests/unit/PersistTest.php, tests/unit/DataTest.php] + db: [tests/Unit/PersistTest.php, tests/Unit/DataTest.php] # add all tests from a directory to api group - api: [tests/functional/api] + api: [tests/Functional/api] ``` A list of tests for the group can be passed from a Group file. It should be defined in plain text with test names on separate lines: ``` -tests/unit/DbTest.php -tests/unit/UserTest.php:creat -tests/unit/UserTest.php:update +tests/Unit/DbTest.php +tests/Unit/UserTest.php:creat +tests/Unit/UserTest.php:update ``` A group file can be included by its relative filename: @@ -542,11 +542,11 @@ You should also specify the path to the `log` directory, where the reports and l It is possible to run specific suites from included applications: * `codecept run` ⬅ Execute all tests from all apps and all suites -* `codecept run unit` ⬅ Runs unit suite from the current app -* `codecept run admin::unit` ⬅ Runs unit suite from admin app -* `codecept run *::unit` ⬅ Runs unit suites from all included apps and NOT the root suite -* `codecept run unit,*::unit` ⬅ Runs included unit suites AND root unit suite -* `codecept run functional,*::unit` ⬅ Runs included unit suites and root functional suite +* `codecept run Unit` ⬅ Runs unit suite from the current app +* `codecept run admin::Unit` ⬅ Runs unit suite from admin app +* `codecept run *::Unit` ⬅ Runs unit suites from all included apps and NOT the root suite +* `codecept run Unit,*::Unit` ⬅ Runs included unit suites AND root unit suite +* `codecept run Functional,*::Unit` ⬅ Runs included unit suites and root functional suite
Improve this guide
diff --git a/docs/ParallelExecution.md b/docs/ParallelExecution.md index 8bf25da4..c3c2a15e 100644 --- a/docs/ParallelExecution.md +++ b/docs/ParallelExecution.md @@ -146,9 +146,9 @@ Codeception can organize tests into [groups](https://codeception.com/docs/Advanc ```bash -tests/functional/LoginCept.php -tests/functional/AdminCest.php:createUser -tests/functional/AdminCest.php:deleteUser +tests/Functional/LoginCept.php +tests/Functional/AdminCest.php:createUser +tests/Functional/AdminCest.php:deleteUser ``` Tasks from `\Codeception\Task\SplitTestsByGroups` will generate non-intersecting group files. You can either split your tests by files or by single tests: @@ -159,7 +159,7 @@ public function parallelSplitTests() // Split your tests by files $this->taskSplitTestFilesByGroups(5) ->projectRoot('.') - ->testsFrom('tests/acceptance') + ->testsFrom('tests/Acceptance') ->groupsTo('tests/Support/Data/paracept_') ->run(); @@ -167,7 +167,7 @@ public function parallelSplitTests() // Split your tests by single tests (alternatively) $this->taskSplitTestsByGroups(5) ->projectRoot('.') - ->testsFrom('tests/acceptance') + ->testsFrom('tests/Acceptance') ->groupsTo('tests/Support/Data/paracept_') ->run(); */ @@ -207,7 +207,7 @@ Let's try to execute tests from the second group: ```bash -php vendor/bin/codecept run acceptance -g paracept_2 +php vendor/bin/codecept run Acceptance -g paracept_2 ``` #### Step 2: Running Tests @@ -228,7 +228,7 @@ public function parallelRun() for ($i = 1; $i <= 5; $i++) { $parallel->process( $this->taskCodecept() // use built-in Codecept task - ->suite('acceptance') // run acceptance tests + ->suite('Acceptance') // run acceptance tests ->group("paracept_$i") // for all paracept_* groups ->xml("tests/_log/result_$i.xml") // save XML results ); diff --git a/docs/ReusingTestCode.md b/docs/ReusingTestCode.md index 18ef9559..9e25f650 100644 --- a/docs/ReusingTestCode.md +++ b/docs/ReusingTestCode.md @@ -95,7 +95,7 @@ Do not hard-code complex CSS or XPath locators in your tests but rather move the Codeception can generate a PageObject class for you with command: ``` -php vendor/bin/codecept generate:pageobject acceptance Login +php vendor/bin/codecept generate:pageobject Acceptance Login ``` > It is recommended to use page objects for acceptance testing only @@ -197,17 +197,17 @@ We call such a classes StepObjects. Lets create an Admin StepObject with the generator: ``` -php vendor/bin/codecept generate:stepobject acceptance Admin +php vendor/bin/codecept generate:stepobject Acceptance Admin ``` You can supply optional action names. Enter one at a time, followed by a newline. End with an empty line to continue to StepObject creation. ``` -php vendor/bin/codecept generate:stepobject acceptance Admin +php vendor/bin/codecept generate:stepobject Acceptance Admin Add action to StepObject class (ENTER to exit): loginAsAdmin Add action to StepObject class (ENTER to exit): -StepObject was created in /tests/acceptance/_support/Step/Acceptance/Admin.php +StepObject was created in /tests/Acceptance/_support/Step/Acceptance/Admin.php ``` This will generate a class in `/tests/Support/Step/Acceptance/Admin.php` similar to this: diff --git a/docs/UnitTests.md b/docs/UnitTests.md index d4d08821..b3bc5137 100644 --- a/docs/UnitTests.md +++ b/docs/UnitTests.md @@ -19,7 +19,7 @@ Create a test using `generate:test` command with a suite and test names as param php vendor/bin/codecept generate:test Unit Example ``` -It creates a new `ExampleTest` file located in the `tests/unit` directory. +It creates a new `ExampleTest` file located in the `tests/Unit` directory. As always, you can run the newly created test with this command: @@ -255,7 +255,7 @@ function testSavingUser() ``` To enable the database functionality in unit tests, make sure the `Db` module is included -in the `unit.suite.yml` configuration file. +in the `Unit.suite.yml` configuration file. The database will be cleaned and populated after each test, the same way it happens for acceptance and functional tests. If that's not your required behavior, change the settings of the `Db` module for the current suite. See [Db Module](https://codeception.com/docs/modules/Db) diff --git a/docs/modules/Apc.md b/docs/modules/Apc.md index 04311256..6efb6a1a 100644 --- a/docs/modules/Apc.md +++ b/docs/modules/Apc.md @@ -30,7 +30,7 @@ Performs a cleanup by flushing all values after each test run. * Stability: **stable** * Contact: serghei@phalcon.io -#### Example (`unit.suite.yml`) +#### Example (`Unit.suite.yml`) {% highlight yaml %} diff --git a/docs/modules/Doctrine.md b/docs/modules/Doctrine.md index 8a72d069..2ce98b63 100644 --- a/docs/modules/Doctrine.md +++ b/docs/modules/Doctrine.md @@ -22,7 +22,7 @@ composer require --dev codeception/module-doctrine Access the database using [Doctrine ORM](https://docs.doctrine-project.org/projects/doctrine-orm/en/latest/). When used with Symfony or Zend Framework 2, Doctrine's Entity Manager is automatically retrieved from Service Locator. -Set up your `functional.suite.yml` like this: +Set up your `Functional.suite.yml` like this: {% highlight yaml %} @@ -50,7 +50,7 @@ By default, the module will wrap everything into a transaction for each test and (this is controlled by the `cleanup` setting). By doing this, tests will run much faster and will be isolated from each other. -To use the Doctrine Module in acceptance tests, set up your `acceptance.suite.yml` like this: +To use the Doctrine Module in acceptance tests, set up your `Acceptance.suite.yml` like this: {% highlight yaml %} diff --git a/docs/modules/Laravel.md b/docs/modules/Laravel.md index 7628ef7f..0a809d44 100644 --- a/docs/modules/Laravel.md +++ b/docs/modules/Laravel.md @@ -47,7 +47,7 @@ See the Acceptance tests section below for more details. * url: `string`, default `` - the application URL. * headers: `array` - default headers are set before each test. -#### Example #1 (`functional.suite.yml`) +#### Example #1 (`Functional.suite.yml`) Enabling module: @@ -59,7 +59,7 @@ modules: {% endhighlight %} -#### Example #2 (`functional.suite.yml`) +#### Example #2 (`Functional.suite.yml`) Enabling module with custom .env file @@ -101,7 +101,7 @@ You should not use this module for acceptance tests. If you want to use Eloquent within your acceptance tests (paired with WebDriver) enable only ORM part of this module: -#### Example (`acceptance.suite.yml`) +#### Example (`Acceptance.suite.yml`) {% highlight yaml %} diff --git a/docs/modules/Memcache.md b/docs/modules/Memcache.md index a0fc65cd..b72f34ac 100644 --- a/docs/modules/Memcache.md +++ b/docs/modules/Memcache.md @@ -34,7 +34,7 @@ Performs a cleanup by flushing all values after each test run. * **`host`** (`string`, default `'localhost'`) - The memcached host * **`port`** (`int`, default `11211`) - The memcached port -#### Example (`unit.suite.yml`) +#### Example (`Unit.suite.yml`) {% highlight yaml %} diff --git a/docs/modules/PhpBrowser.md b/docs/modules/PhpBrowser.md index f72e65c6..2e35217f 100644 --- a/docs/modules/PhpBrowser.md +++ b/docs/modules/PhpBrowser.md @@ -46,7 +46,7 @@ If test fails stores last shown page in 'output' dir. * .. those and other [Guzzle Request options](https://docs.guzzlephp.org/en/latest/request-options.html) -#### Example (`acceptance.suite.yml`) +#### Example (`Acceptance.suite.yml`) modules: enabled: diff --git a/docs/modules/Redis.md b/docs/modules/Redis.md index 3c4505eb..e39ebce9 100644 --- a/docs/modules/Redis.md +++ b/docs/modules/Redis.md @@ -40,7 +40,7 @@ to interact with a Redis server. Note: The full configuration list can be found on Predis' github. -#### Example (`unit.suite.yml`) +#### Example (`Unit.suite.yml`) {% highlight yaml %} diff --git a/docs/modules/WebDriver.md b/docs/modules/WebDriver.md index 6c227098..9426c742 100644 --- a/docs/modules/WebDriver.md +++ b/docs/modules/WebDriver.md @@ -273,7 +273,7 @@ modules: ### Loading Parts from other Modules -While all Codeception modules are designed to work stand-alone, it's still possible to load *several* modules at once. To use e.g. the [Asserts module](https://codeception.com/docs/modules/Asserts) in your acceptance tests, just load it like this in your `acceptance.suite.yml`: +While all Codeception modules are designed to work stand-alone, it's still possible to load *several* modules at once. To use e.g. the [Asserts module](https://codeception.com/docs/modules/Asserts) in your acceptance tests, just load it like this in your `Acceptance.suite.yml`: {% highlight yaml %} @@ -403,7 +403,7 @@ public function _before(TestInterface $test) {% endhighlight %} -to make this work load `\Helper\Acceptance` before `WebDriver` in `acceptance.suite.yml`: +to make this work load `\Helper\Acceptance` before `WebDriver` in `Acceptance.suite.yml`: {% highlight yaml %} diff --git a/docs/modules/Yii2.md b/docs/modules/Yii2.md index 96f91770..f7454985 100644 --- a/docs/modules/Yii2.md +++ b/docs/modules/Yii2.md @@ -79,7 +79,7 @@ This section details what you can expect when using this module. * `recreateApplication` - (default: `false`) whether to recreate the whole application before each request -You can use this module by setting params in your `functional.suite.yml`: +You can use this module by setting params in your `Functional.suite.yml`: {% highlight yaml %} @@ -105,7 +105,7 @@ available parts are: See [WebDriver module](https://codeception.com/docs/modules/WebDriver#Loading-Parts-from-other-Modules) for general information on how to load parts of a framework module. -#### Example (`acceptance.suite.yml`) +#### Example (`Acceptance.suite.yml`) {% highlight yaml %} diff --git a/docs/reference/Commands.md b/docs/reference/Commands.md index f5575bdc..83182a5f 100644 --- a/docs/reference/Commands.md +++ b/docs/reference/Commands.md @@ -11,16 +11,16 @@ Executes tests. Usage: -* `codecept run acceptance`: run all acceptance tests -* `codecept run tests/acceptance/MyCest.php`: run only MyCest -* `codecept run acceptance MyCest`: same as above -* `codecept run acceptance MyCest:myTestInIt`: run one test from a Cest -* `codecept run acceptance MyCest:myTestInIt#1`: run one example or data provider item by number -* `codecept run acceptance MyCest:myTestInIt#1-3`: run a range of examples or data provider items -* `codecept run acceptance MyCest:myTestInIt@name.*`: run data provider items with matching names -* `codecept run acceptance checkout.feature`: run feature-file -* `codecept run acceptance -g slow`: run tests from *slow* group -* `codecept run unit,functional`: run only unit and functional suites +* `codecept run Acceptance`: run all acceptance tests +* `codecept run tests/Acceptance/MyCest.php`: run only MyCest +* `codecept run Acceptance MyCest`: same as above +* `codecept run Acceptance MyCest:myTestInIt`: run one test from a Cest +* `codecept run Acceptance MyCest:myTestInIt#1`: run one example or data provider item by number +* `codecept run Acceptance MyCest:myTestInIt#1-3`: run a range of examples or data provider items +* `codecept run Acceptance MyCest:myTestInIt@name.*`: run data provider items with matching names +* `codecept run Acceptance checkout.feature`: run feature-file +* `codecept run Acceptance -g slow`: run tests from *slow* group +* `codecept run Unit,Functional`: run only unit and functional suites Verbosity modes: @@ -109,7 +109,7 @@ Starting from Codeception 2.0 actor classes are auto-generated. Use this command Prints all steps from all Gherkin contexts for a specific suite {% highlight yaml %} -codecept gherkin:steps acceptance +codecept gherkin:steps Acceptance {% endhighlight %} @@ -137,10 +137,10 @@ Creates empty GroupObject - extension which handles all group events. Shows step by step execution process for scenario driven tests without actually running them. -* `codecept dry-run acceptance` -* `codecept dry-run acceptance MyCest` -* `codecept dry-run acceptance checkout.feature` -* `codecept dry-run tests/acceptance/MyCest.php` +* `codecept dry-run Acceptance` +* `codecept dry-run Acceptance MyCest` +* `codecept dry-run Acceptance checkout.feature` +* `codecept dry-run tests/Acceptance/MyCest.php` @@ -153,8 +153,8 @@ Shows step by step execution process for scenario driven tests without actually Generates skeleton for Unit Test that extends `Codeception\TestCase\Test`. -* `codecept g:test unit User` -* `codecept g:test unit "App\User"` +* `codecept g:test Unit User` +* `codecept g:test Unit "App\User"` @@ -184,7 +184,7 @@ Creates empty Helper class. Try to execute test commands in run-time. You may try commands before writing the test. -* `codecept console acceptance` - starts acceptance suite environment. If you use WebDriver you can manipulate browser with Codeception commands. +* `codecept console Acceptance` - starts acceptance suite environment. If you use WebDriver you can manipulate browser with Codeception commands. @@ -195,7 +195,7 @@ If PageObject is generated globally it will act as UIMap, without any logic in i * `codecept g:page Login` * `codecept g:page Registration` -* `codecept g:page acceptance Login` +* `codecept g:page Acceptance Login` @@ -203,8 +203,8 @@ If PageObject is generated globally it will act as UIMap, without any logic in i Generates StepObject class. You will be asked for steps you want to implement. -* `codecept g:stepobject acceptance AdminSteps` -* `codecept g:stepobject acceptance UserSteps --silent` - skip action questions +* `codecept g:stepobject Acceptance AdminSteps` +* `codecept g:stepobject Acceptance UserSteps --silent` - skip action questions @@ -216,10 +216,10 @@ Code snippets are expected to be implemented in Actor or PageObjects Usage: -* `codecept gherkin:snippets acceptance` - snippets from all feature of acceptance tests -* `codecept gherkin:snippets acceptance/feature/users` - snippets from `feature/users` dir of acceptance tests -* `codecept gherkin:snippets acceptance user_account.feature` - snippets from a single feature file -* `codecept gherkin:snippets acceptance/feature/users/user_accout.feature` - snippets from feature file in a dir +* `codecept gherkin:snippets Acceptance` - snippets from all feature of acceptance tests +* `codecept gherkin:snippets Acceptance/feature/users` - snippets from `feature/users` dir of acceptance tests +* `codecept gherkin:snippets Acceptance user_account.feature` - snippets from a single feature file +* `codecept gherkin:snippets Acceptance/feature/users/user_accout.feature` - snippets from feature file in a dir @@ -283,7 +283,7 @@ If suite name is provided, an actor class will be included into placeholder * `codecept g:snapshot UserEmails` * `codecept g:snapshot Products` -* `codecept g:snapshot acceptance UserEmails` +* `codecept g:snapshot Acceptance UserEmails` @@ -295,7 +295,7 @@ Use it do debug Yaml configs Check config: * `codecept config`: check global config -* `codecept config unit`: check suite config +* `codecept config Unit`: check suite config Load config: @@ -327,9 +327,9 @@ Create new test suite. Requires suite name and actor name Generates user-friendly text scenarios from scenario-driven tests (Cest). -* `codecept g:scenarios acceptance` - for all acceptance tests -* `codecept g:scenarios acceptance --format html` - in html format -* `codecept g:scenarios acceptance --path doc` - generate scenarios to `doc` dir +* `codecept g:scenarios Acceptance` - for all acceptance tests +* `codecept g:scenarios Acceptance --format html` - in html format +* `codecept g:scenarios Acceptance --path doc` - generate scenarios to `doc` dir diff --git a/docs/reference/Configuration.md b/docs/reference/Configuration.md index ce366e19..ea9bc349 100644 --- a/docs/reference/Configuration.md +++ b/docs/reference/Configuration.md @@ -105,7 +105,7 @@ Possible settings: * `shuffle: true`: Randomize test order * `strict_xml: false`: Generate XML JUnit report using strict schema. Avoid putting additional report fields like steps or scenario names to it. Required for XML reports on Jenkins CI -## Suite Configuration: `unit.suite.yml`, `functional.suite.yml` etc. +## Suite Configuration: `Unit.suite.yml`, `Functional.suite.yml` etc. Each suite has its own configuration inside the directory set by `paths: tests: ` in `codeception.yml`. Alphabetical list of options: @@ -178,12 +178,12 @@ Default namespace for new tests of this suite (ignores `namespace` option) To provide the same configuration template for your development team, you can create a `codeception.dist.yml` config file, which will be loaded before `codeception.yml`. The dist config provides shared options, while local `codeception.yml` files override them on a per-installation basis. Therefore, `codeception.yml` should be ignored by your VCS system. -Config templates can also be used for suite configuration, by creating a `suitename.suite.dist.yml` file. +Config templates can also be used for suite configuration, by creating a `suitename.Suite.dist.yml` file. Configuration loading order: 1. `codeception.dist.yml` 2. `codeception.yml` -3. `acceptance.suite.dist.yml` -4. `acceptance.suite.yml` +3. `Acceptance.suite.dist.yml` +4. `Acceptance.suite.yml` 5. environment config diff --git a/for/laravel.md b/for/laravel.md index f96ef465..3b55cbe7 100644 --- a/for/laravel.md +++ b/for/laravel.md @@ -47,7 +47,7 @@ cp .env .env.testing Functional tests allow test application by simulating user actions, this is done by sending requests to framework kernel and checking HTML as a result. Unilke internal tests of Laravel, Codeception doesn't limit you to testing only one request per test. You can **test complex interactions involving different actions and controllers**. This way you can easily cover your specifictions with functional tests. -To start you need to configure `tests/functional.suite.yml` to use Laravel module: +To start you need to configure `tests/Functional.suite.yml` to use Laravel module: ```yaml class_name: FunctionalTester @@ -77,10 +77,10 @@ php vendor/bin/codecept g:cest functional Login To generate a unit test run: ``` -php vendor/bin/codecept g:test unit "Foo\Bar" +php vendor/bin/codecept g:test Unit "Foo\Bar" ``` This generates `Codeception\Test\Unit` testcase which is inherited from PHPUnit but provides a module access. -Enable Laravel module in `unit.suite.yml` to have its methods inside a testcase. They are available injected into `$this->tester` property of a testcase. +Enable Laravel module in `Unit.suite.yml` to have its methods inside a testcase. They are available injected into `$this->tester` property of a testcase.
@@ -90,7 +90,7 @@ Enable Laravel module in `unit.suite.yml` to have its methods inside a testcase. ### Acceptance Tests -To test an application in a real environment by using its UI you should use a real browser. Codeception uses Selenium Webdriver and corresponding WebDriver module to interact with a browser. You should configure `acceptance.suite.yml` to use WebDriver module and a browser of your choice. +To test an application in a real environment by using its UI you should use a real browser. Codeception uses Selenium Webdriver and corresponding WebDriver module to interact with a browser. You should configure `Acceptance.suite.yml` to use WebDriver module and a browser of your choice. ```yaml class_name: AcceptanceTester @@ -157,13 +157,13 @@ Laravel module actions like `amOnPage` or `see` should not be available for test ### BDD -If you prefer to describe application with feature files, Codeception can turn them to acceptance or functional tests. It is recommended to store feature files in `features` directory (like it does Behat) but symlinking it to `tests/acceptance/features` or `tests/functional/features` so they can be treated as tests too. For using BDD with acceptance tests you need to run: +If you prefer to describe application with feature files, Codeception can turn them to acceptance or functional tests. It is recommended to store feature files in `features` directory (like it does Behat) but symlinking it to `tests/Acceptance/features` or `tests/Functional/features` so they can be treated as tests too. For using BDD with acceptance tests you need to run: ``` -ln -s $PWD/features tests/acceptance +ln -s $PWD/features tests/Acceptance ``` -Codeception allows to combine tests written in different formats. If are about to wirite a regression test it probably should not be described as a product's feature. That's why feature-files is subset of all acceptance tests, and they are stored in subfolder of `tests/acceptance`. +Codeception allows to combine tests written in different formats. If are about to wirite a regression test it probably should not be described as a product's feature. That's why feature-files is subset of all acceptance tests, and they are stored in subfolder of `tests/Acceptance`. 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. diff --git a/for/phalcon.md b/for/phalcon.md index 875036c4..2be2084c 100644 --- a/for/phalcon.md +++ b/for/phalcon.md @@ -36,7 +36,7 @@ This will create `tests` directory and configuration file `codeception.yml`. Thi ### Unit Testing -Add Phalcon to your unit test by adding the following to your `unit.suite.yml`: +Add Phalcon to your unit test by adding the following to your `Unit.suite.yml`: ```yaml # Codeception Test Suite Configuration # @@ -57,7 +57,7 @@ modules: To generate a plain PHPUnit test for class `Users`, run: ``` -vendor/bin/codecept g:test unit Users +vendor/bin/codecept g:test Unit Users ``` Actions of the Phalcon module will be accessible from `$this->tester` inside a test of `Codeception\Test\Unit`. @@ -95,7 +95,7 @@ modules: Then use [Cest](https://codeception.com/docs/07-AdvancedUsage) or Cept to create a test. ``` -vendor/bin/codecept g:cest functional Login +vendor/bin/codecept g:cest Functional Login ``` Then add your test case ```php @@ -138,7 +138,7 @@ class LoginCest ### Acceptance Testing -Sample configuration of `tests/acceptance.suite.yml`: +Sample configuration of `tests/Acceptance.suite.yml`: ```yaml class_name: AcceptanceTester @@ -155,10 +155,10 @@ Browser can be specified as `chrome`, `firefox`, `phantomjs`, or others. To create a sample test called, run: ``` -vendor/bin/codecept g:cest acceptance Login +vendor/bin/codecept g:cest Acceptance Login ``` -This will create the file `tests/acceptance/LoginCest.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`. +This will create the file `tests/Acceptance/LoginCest.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`.
@@ -168,7 +168,7 @@ This will create the file `tests/acceptance/LoginCest.php`. Each method of a cla To run the tests you will need chrome browser, [selenium server running](https://codeception.com/docs/modules/WebDriver#Selenium). If this requirements met acceptance tests can be executed as ``` -vendor/bin/codecept run acceptance +vendor/bin/codecept run Acceptance ``` ### BDD @@ -176,7 +176,7 @@ vendor/bin/codecept run acceptance 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 +ln -s $PWD/features tests/Acceptance ``` 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`. diff --git a/for/yii.md b/for/yii.md index 293078b7..592e369e 100644 --- a/for/yii.md +++ b/for/yii.md @@ -35,7 +35,7 @@ Run them by executing in terminal: ### Unit Tests -Unit tests are located in `tests/unit` directory and are supposed to contain all kind of unit and integration testing. +Unit tests are located in `tests/Unit` directory and are supposed to contain all kind of unit and integration testing. Each test case extends `Codeception\Test\Unit` class, which is standard Codeception format for unit testing. It is pretty hard to develop completely isolated unit tests in Yii, so an application is bootstrapped before each test case. Tests are configured in `tests/unit.suite.yml` file with Yii2 module enabled: @@ -152,10 +152,10 @@ Yii2 module actions like `amOnPage` or `see` should not be available for testing From a test perspective acceptance tests do the same as functional tests. They test the user interaction with application but in this case using *real* browser and web server. They are much slower and much more fragile. They should not duplicate functional tests in matter of testing functionality but should be used for testing the UI of your application. If you are unsure which tests should be acceptance and which are functional, write acceptance tests for JavaScript-rich applications, where UI highly depends on a browser processing. You can also use acceptance tests for happy-path scenarios, just to ensure that a real user using a real browser achieve the same results you expect in functional tests. -By default in basic application acceptance tests are disabled (as they require web server, Selenium Server and browser to be running). You can easily enable them by renaming `acceptance.suite.yml.example` to `acceptance.suite.yml` +By default in basic application acceptance tests are disabled (as they require web server, Selenium Server and browser to be running). You can easily enable them by renaming `Acceptance.suite.yml.example` to `Acceptance.suite.yml` ``` -mv tests/acceptance.suite.yml.example tests/acceptance.suite.yml +mv tests/Acceptance.suite.yml.example tests/Acceptance.suite.yml ``` Basic template uses `codeception/base` package which doesn't contain `facebook/webdriver` library required to run acceptance tests. Please change `codeception/base` to `codeception/codeception` in `composer.json` and run the update command. @@ -169,7 +169,7 @@ Then you will need to launch application server in test mode: and start a [Selenium Server](https://codeception.com/docs/modules/WebDriver#Local-Testing). For acceptance WebDriver module is used. Please check its reference to learn how to work with it. Unlike Yii2 module it does know nothing about your application, so if you want to use features of Yii like fixtures for acceptance testing, you should check that enable Yii2 module is enabled as well: ```yml -# config at tests/acceptance.yml +# config at tests/Acceptance.yml modules: enabled: - WebDriver: @@ -186,7 +186,7 @@ As it was said, functional and acceptance tests are similar, so in order to avoi Similar as for functional tests it is recommended to use Cest format for acceptance testing: ``` -./vendor/bin/codecept g:cest acceptance MyNewScenarioCest +./vendor/bin/codecept g:cest Acceptance MyNewScenarioCest ```
@@ -222,10 +222,10 @@ Create basic test suites ./vendor/bin/codecept bootstrap ``` -Enable module Yii2 for functional tests inside `functional.suite.yml`: +Enable module Yii2 for functional tests inside `Functional.suite.yml`: ```yml -# functional.suite.yml +# Functional.suite.yml modules: enabled: - Yii2: