Skip to content
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

magento/devdocs#: Add documentation about @magentoConfigFixture annotation #5086

Merged
merged 4 commits into from
Jul 31, 2019
Merged
Changes from 3 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
46 changes: 45 additions & 1 deletion guides/v2.3/graphql/functional-testing.md
Original file line number Diff line number Diff line change
Expand Up @@ -95,7 +95,7 @@ A fixture consists of two files:
- The fixture file, which defines the test
- A rollback file, which reverts the system to the state before the test was run

{:.bs-callout .bs-callout-info}
{: .bs-callout-info }
Each fixture should have a corresponding rollback file.

Magento provides fixtures in the `dev/tests/integration/testsuite/Magento/<ModuleName>/_files` directory. Use these fixtures whenever possible. When you create your own fixture, also create a proper rollback.
Expand Down Expand Up @@ -196,6 +196,50 @@ $registry->unregister('isSecureArea');
$registry->register('isSecureArea', false);
```

### Fixture configs

Use the `@magentoConfigFixture` annotation to set a custom config value. It supports a `store` scope only.

#### Syntax

```php
/**
* @magentoConfigFixture <store_code>_store <config_key> <config_value>
*/
```

where
- `<store_code>` - Store code. See the `store`.`code` database field value.
- `<config_key>` - Config key. See `core_config_data`.`path`
- `<config_value>` - Config value. See `core_config_data`.`value`

{: .bs-callout-info }
`@magentoConfigFixture` does not require a roll-back.

#### Example usage

The following example sets a store-scoped value `1` for the config key `checkout/options/enable_agreements` for the `default` store in the `GetActiveAgreement()` test:

```php
/**
* @magentoConfigFixture default_store checkout/options/enable_agreements 1
*/
public function testGetActiveAgreement()
{
...
}
```

`@magentoConfigFixture` performs the following action as a background process before test execution:

```sql
INSERT INTO `core_config_data` (scope`, `scope_id`, `path`, `value`)
VALUES
('stores', 1, 'checkout/options/enable_agreements', '1');
```

The fixture automatically removes the `checkout/options/enable_agreements` config key from the database after the test has been completed.

## Defining expected exceptions

Your functional tests should include events that cause exceptions. Since your tests expect an exception to occur, set up your tests so that they elicit the proper responses. You can define expected exception messages either in:
Expand Down