Use upper-cased suite names to match the default directory structure used by codeception v5

Author: W0rma

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

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.
 
 
 <div class="alert alert-warning"><a href="https://github.com/Codeception/codeception.github.com/edit/master/docs/APITesting.md"><strong>Improve</strong> this guide</a></div>

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

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:

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.

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

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

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
 
 
 <div class="alert alert-warning"><a href="https://github.com/Codeception/codeception.github.com/edit/master/docs/Customization.md"><strong>Improve</strong> this guide</a></div>

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,15 +159,15 @@ public function parallelSplitTests()
     // Split your tests by files
     $this->taskSplitTestFilesByGroups(5)
         ->projectRoot('.')
-        ->testsFrom('tests/acceptance')
+        ->testsFrom('tests/Acceptance')
         ->groupsTo('tests/Support/Data/paracept_')
         ->run();
 
     /*
     // 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
         );

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: