Use upper-cased suite names

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

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)
 

docs/modules/Apc.md

@@ -30,7 +30,7 @@ Performs a cleanup by flushing all values after each test run.
 * Stability: **stable**
 * Contact: [email protected]
 
-#### Example (`unit.suite.yml`)
+#### Example (`Unit.suite.yml`)
 
 {% highlight yaml %}