Added Diff module. #42
Conversation
WalkthroughThe changes introduce the Drupal Diff module and its configuration, enabling revision comparison functionality. New permissions are granted to authenticated users, and related settings are established. Behat testing is expanded with a new feature test for revision comparison and additional step definitions to support navigation and form interaction. Documentation is updated with stricter contribution guidelines. Changes
Sequence Diagram(s)sequenceDiagram
participant AdminUser
participant WebUI
participant DrupalBackend
participant DiffModule
AdminUser->>WebUI: Log in as admin
AdminUser->>WebUI: Create new content (node) with summary
WebUI->>DrupalBackend: Save node (Revision 1)
AdminUser->>WebUI: Edit content, update summary
WebUI->>DrupalBackend: Save node (Revision 2)
AdminUser->>WebUI: Navigate to revisions page
WebUI->>DrupalBackend: Request revisions list
AdminUser->>WebUI: Select two revisions for comparison
WebUI->>DrupalBackend: Trigger compare action
DrupalBackend->>DiffModule: Compare selected revisions
DiffModule-->>DrupalBackend: Return comparison results
DrupalBackend-->>WebUI: Display revision comparison
WebUI-->>AdminUser: Show changes between revisions
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (3)
config/default/user.role.authenticated.yml (1)
21-28: 🧹 Nitpick (assertive)Consider grouping related permissions
For readability, you may want to keepcompare revisionsandview revisionsadjacent without interleaving other permissions.Example diff to reorder:
- 'access site-wide contact form' - - 'compare revisions' - 'delete own files' - 'use text format webform_default' - 'view media' + - 'compare revisions' + - 'view revisions'CLAUDE.md (2)
105-110:⚠️ Potential issueFix numbering in “Adding New Features” list
The steps are misnumbered (two “2.” entries), which can confuse readers.Apply this diff:
-1. Switch to `develop` branch and pull the latest changes -2. Create a feature branch from `develop` in the format `feature/name` -2. Implement the feature -3. Export configuration changes using `ahoy drush cex -y` -4. Write appropriate tests -5. Run coding standards checks -6. Commit the code with a message in the format `Verb in past tense with a period at the end.` -7. Do not push to remote. +1. Switch to `develop` branch and pull the latest changes +2. Create a feature branch from `develop` in the format `feature/name` +3. Implement the feature +4. Export configuration changes using `ahoy drush cex -y` +5. Write appropriate tests +6. Run coding standards checks +7. Commit the code with a message in the format `Verb in past tense with a period at the end.` +8. Do not push to remote.
115-121:⚠️ Potential issueFix numbering in “Bug Fixes” list
Similarly, the bugfix steps start with two “2.” entries.Apply this diff:
-1. Switch to `develop` branch and pull the latest changes -2. Create a bugfix branch from `develop` in the format `bugfix/name` -2. Fix the issue -3. Export configuration changes using `ahoy drush cex -y` -4. Add tests to prevent regression -5. Commit the code with a message in the format `Verb in past tense with a period at the end.` -6. Do not push to remote. +1. Switch to `develop` branch and pull the latest changes +2. Create a bugfix branch from `develop` in the format `bugfix/name` +3. Fix the issue +4. Export configuration changes using `ahoy drush cex -y` +5. Add tests to prevent regression +6. Commit the code with a message in the format `Verb in past tense with a period at the end.` +7. Do not push to remote.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Lite
⛔ Files ignored due to path filters (1)
composer.lockis excluded by!**/*.lock
📒 Files selected for processing (8)
CLAUDE.md(4 hunks)composer.json(1 hunks)config/default/core.entity_view_mode.node.diff.yml(1 hunks)config/default/core.extension.yml(1 hunks)config/default/diff.settings.yml(1 hunks)config/default/user.role.authenticated.yml(2 hunks)tests/behat/bootstrap/FeatureContext.php(3 hunks)tests/behat/features/diff.feature(1 hunks)
🔇 Additional comments (12)
composer.json (2)
19-19: Dependency addition looks correct
You’ve inserted"drupal/diff": "^1.8"in the proper alphabetical place.
19-19: Verify version compatibility with Drupal 11
Please confirm that the^1.8constraint aligns with the supported releases of the Diff module for Drupal 11 and doesn’t introduce breaking changes.config/default/core.extension.yml (1)
26-26: Module enabled correctly
Addingdiff: 0under themodule:section properly activates the Diff module in core.extension.yml. The alphabetical ordering and weight are consistent with other entries.config/default/user.role.authenticated.yml (2)
9-9: Dependency on Diff module added
Including- diffunderdependencies: module:ensures that the authenticated role config only applies when the Diff module is present.
23-24: New permissions granted correctly
You’ve addedcompare revisionsandview revisionsto enable revision comparison functionality.config/default/core.entity_view_mode.node.diff.yml (2)
4-10: Validate configuration dependencies structure
You’ve declarednodeunderdependencies.moduleand bothnodeanddiffunderdependencies.enforced.module. Please verify that this matches Drupal’s expected format for entity view mode configs—typically both modules appear underdependencies.module.
1-3: Entity view mode definition is sound
Theid,label,targetEntityType, and caching flag are correctly defined, and the status is set tofalseto prevent unintended exposure.Also applies to: 11-17
config/default/diff.settings.yml (1)
1-20: Configuration looks appropriate for the Diff moduleThe configuration includes all the essential settings for the Diff module with sensible defaults:
- Context lines (1 before and after changes) provide enough context without overwhelming the diff view
- Three layout plugins enabled with appropriate weighting to control their display order
- Revision pager limit of 50 with pager disabled (line 20)
The configuration aligns well with standard Drupal practices for the Diff module.
tests/behat/features/diff.feature (1)
1-24: Well-structured test scenario for the Diff moduleThe test covers the complete revision comparison workflow:
- Creating initial content
- Updating content to create a revision
- Navigating to revisions page
- Selecting specific revisions for comparison
- Verifying that both versions are displayed
The test is properly tagged with
@apiand@p1for priority, and includes a clear user story explaining the purpose of the feature.tests/behat/bootstrap/FeatureContext.php (3)
13-13: LGTM: ElementTrait import addedAppropriate addition of the ElementTrait which will be used for radio button selection.
31-31: LGTM: ElementTrait included in classCorrectly added the trait to the class definition.
74-92: LGTM: Well-implemented radio button selection by IDThe function correctly:
- Finds a radio button element by ID
- Handles the case when the element is not found
- Retrieves its value attribute
- Selects the option with that value
This implementation is robust and includes proper error handling.
| ## Important information | ||
|
|
||
| - Never modify .gitignore file unless I ask you explicitly. | ||
| - Never change PHPCS, PHPStan or PHPUnit configuration unless I ask you explicitly. | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Important Information section added
The new guidelines guard against unintentional .gitignore and config changes. Consider capitalizing the heading as Important Information for consistency with other section titles.
| /** | ||
| * Visit a revisions page of a type with a specified title. | ||
| * | ||
| * @code | ||
| * When I visit the "article" content revisions page with the title "Test article" | ||
| * @endcode | ||
| * | ||
| * @When I visit the :content_type content revisions page with the title :title | ||
| */ | ||
| public function visitScheduledTransitionsPageWithTitle(string $content_type, string $title): void { | ||
| $this->contentVisitActionPageWithTitle($content_type, $title, '/revisions'); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Function name doesn't match its purpose
The function name visitScheduledTransitionsPageWithTitle suggests it's for scheduled transitions, but it's actually being used to visit revision pages.
- public function visitScheduledTransitionsPageWithTitle(string $content_type, string $title): void {
+ public function visitRevisionsPageWithTitle(string $content_type, string $title): void {
$this->contentVisitActionPageWithTitle($content_type, $title, '/revisions');
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /** | |
| * Visit a revisions page of a type with a specified title. | |
| * | |
| * @code | |
| * When I visit the "article" content revisions page with the title "Test article" | |
| * @endcode | |
| * | |
| * @When I visit the :content_type content revisions page with the title :title | |
| */ | |
| public function visitScheduledTransitionsPageWithTitle(string $content_type, string $title): void { | |
| $this->contentVisitActionPageWithTitle($content_type, $title, '/revisions'); | |
| } | |
| /** | |
| * Visit a revisions page of a type with a specified title. | |
| * | |
| * @code | |
| * When I visit the "article" content revisions page with the title "Test article" | |
| * @endcode | |
| * | |
| * @When I visit the :content_type content revisions page with the title :title | |
| */ | |
| public function visitRevisionsPageWithTitle(string $content_type, string $title): void { | |
| $this->contentVisitActionPageWithTitle($content_type, $title, '/revisions'); | |
| } |
AlexSkrypnyk
force-pushed
the
feature/diff-module-integration
branch
from
13df292 to
692aa09
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (2)
CLAUDE.md (2)
36-40: Capitalize the heading for consistency
Section titles elsewhere use Title Case. Update## Important informationto## Important Information.
82-87: Wrap the User Story in a fenced code block
Per the BDD formatting guidelines, the user story should be enclosed in a fenced code block withgherkinlanguage specifier for clarity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Lite
⛔ Files ignored due to path filters (1)
composer.lockis excluded by!**/*.lock
📒 Files selected for processing (8)
CLAUDE.md(4 hunks)composer.json(1 hunks)config/default/core.entity_view_mode.node.diff.yml(1 hunks)config/default/core.extension.yml(1 hunks)config/default/diff.settings.yml(1 hunks)config/default/user.role.authenticated.yml(2 hunks)tests/behat/bootstrap/FeatureContext.php(3 hunks)tests/behat/features/diff.feature(1 hunks)
🔇 Additional comments (12)
composer.json (1)
19-19: Verify the version constraint for drupal/diff
Ensure that^1.8aligns with the required branch for Drupal 11 and that there are no known compatibility issues or security advisories for this version.config/default/diff.settings.yml (4)
1-2: Approve default_config_hash as expected
Thedefault_config_hashis auto-generated by Drupal’s configuration system; no manual updates needed.
3-7: Approve general settings structure
The defaultradio_behavior, context lines, and revision pager limit align with typical Diff module configurations.
8-17: Verify layout plugin weights
Negative weights are used to order the Diff layout plugins. Confirm these values produce the desired plugin ordering in practice.
18-20: Verify revision_pager type and behavior
Therevision_pageris set as a string'0'. Ensure the module interprets this correctly (disabling pagination) and that string typing won’t cause unexpected behavior.config/default/core.extension.yml (1)
26-26: Module enabled in core.extension.yml
Thediffmodule has been correctly added with a weight of 0, and the ordering in the module list remains alphabetical.config/default/user.role.authenticated.yml (2)
9-9: Add diff module to role dependencies
The authenticated user role now depends on thediffmodule, ensuring the config is applied after the module is installed.
23-23: Review permissions granted to authenticated users
Grantingcompare revisionsandview revisionsto all authenticated users may expose revision histories. Confirm this aligns with your security and content governance policies.Also applies to: 27-27
config/default/core.entity_view_mode.node.diff.yml (1)
1-17: Configuration follows Drupal standardsThe entity view mode configuration for node revision comparison is well-structured and includes all required elements. The enforced dependencies correctly specify both the
nodeanddiffmodules, ensuring they cannot be uninstalled while this configuration is present.tests/behat/features/diff.feature (1)
1-24: Well-structured Behat test for revision comparisonThe test scenario effectively validates the Diff module's core functionality with a comprehensive workflow from content creation through revision comparison. The scenario follows best practices by using specific assertions to verify the comparison output.
tests/behat/bootstrap/FeatureContext.php (2)
13-13: ElementTrait integration looks goodThe import and usage of ElementTrait is correctly implemented to support the new radio button selection functionality.
Also applies to: 31-31
61-72: Well-documented method for visiting revision pagesThe method is properly implemented and addresses the previous feedback about the method name matching its purpose.
| /** | ||
| * Select a radio button by its ID. | ||
| * | ||
| * @code | ||
| * When I select the radio button with the id "my-radio-button" | ||
| * @endcode | ||
| * | ||
| * @When I select the radio button with the id :id | ||
| */ | ||
| public function assertSelectRadioByIdOnly(string $id = ''): void { | ||
| $radiobutton = $this->getSession()->getPage()->findById($id); | ||
|
|
||
| if ($radiobutton === NULL) { | ||
| throw new \Exception(sprintf('The radio button with id "%s" was not found on the page', $id)); | ||
| } | ||
|
|
||
| $value = $radiobutton->getAttribute('value'); | ||
| $radiobutton->selectOption($value); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider adding element type validation
The radio button selection method works well, but consider adding validation to ensure the found element is actually a radio input.
public function assertSelectRadioByIdOnly(string $id = ''): void {
$radiobutton = $this->getSession()->getPage()->findById($id);
if ($radiobutton === NULL) {
throw new \Exception(sprintf('The radio button with id "%s" was not found on the page', $id));
}
+ // Verify that the found element is actually a radio button
+ if ($radiobutton->getAttribute('type') !== 'radio') {
+ throw new \Exception(sprintf('The element with id "%s" is not a radio button', $id));
+ }
$value = $radiobutton->getAttribute('value');
$radiobutton->selectOption($value);
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /** | |
| * Select a radio button by its ID. | |
| * | |
| * @code | |
| * When I select the radio button with the id "my-radio-button" | |
| * @endcode | |
| * | |
| * @When I select the radio button with the id :id | |
| */ | |
| public function assertSelectRadioByIdOnly(string $id = ''): void { | |
| $radiobutton = $this->getSession()->getPage()->findById($id); | |
| if ($radiobutton === NULL) { | |
| throw new \Exception(sprintf('The radio button with id "%s" was not found on the page', $id)); | |
| } | |
| $value = $radiobutton->getAttribute('value'); | |
| $radiobutton->selectOption($value); | |
| } | |
| /** | |
| * Select a radio button by its ID. | |
| * | |
| * @code | |
| * When I select the radio button with the id "my-radio-button" | |
| * @endcode | |
| * | |
| * @When I select the radio button with the id :id | |
| */ | |
| public function assertSelectRadioByIdOnly(string $id = ''): void { | |
| $radiobutton = $this->getSession()->getPage()->findById($id); | |
| if ($radiobutton === NULL) { | |
| throw new \Exception(sprintf('The radio button with id "%s" was not found on the page', $id)); | |
| } | |
| // Verify that the found element is actually a radio button | |
| if ($radiobutton->getAttribute('type') !== 'radio') { | |
| throw new \Exception(sprintf('The element with id "%s" is not a radio button', $id)); | |
| } | |
| $value = $radiobutton->getAttribute('value'); | |
| $radiobutton->selectOption($value); | |
| } |
AlexSkrypnyk
force-pushed
the
feature/diff-module-integration
branch
from
692aa09 to
4e21998
Compare
AlexSkrypnyk
force-pushed
the
feature/diff-module-integration
branch
from
4e21998 to
08aca97
Compare
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 3
♻️ Duplicate comments (2)
CLAUDE.md (1)
36-40: Capitalize heading for consistency
Change## Important informationto## Important Informationto match the title-casing used in other sections.tests/behat/bootstrap/FeatureContext.php (1)
83-92: Element type validation still missing in radio button selectionThe method doesn't validate whether the element is actually a radio input before attempting to interact with it. If the element with the specified ID exists but is not a radio button, this could lead to unexpected behavior or confusing error messages.
As suggested in a previous review (which is still valid), you should add validation to ensure the found element is a radio button.
public function assertSelectRadioByIdOnly(string $id = ''): void { $radiobutton = $this->getSession()->getPage()->findById($id); if ($radiobutton === NULL) { throw new \Exception(sprintf('The radio button with id "%s" was not found on the page', $id)); } + // Verify that the found element is actually a radio button + if ($radiobutton->getAttribute('type') !== 'radio') { + throw new \Exception(sprintf('The element with id "%s" is not a radio button', $id)); + } $value = $radiobutton->getAttribute('value'); $radiobutton->selectOption($value); }
🛑 Comments failed to post (3)
config/default/core.entity_view_mode.node.diff.yml (1)
11-17: 🧹 Nitpick (assertive)
Add a description for clarity
Thedescriptionfield is currentlynull. Consider adding a brief description (e.g., "Displays side-by-side content revisions") to help site builders understand the purpose of this view mode.CLAUDE.md (2)
82-87: 🧹 Nitpick (assertive)
Wrap BDD user story in a fenced code block
To improve readability and maintain consistency with Gherkin syntax, wrap theAs a / I want / So thatlines in a fenced code block under the "User story" bullet. For example:- - User story: A description of the user story being tested in a format: - As a <role> - I want <feature> - So that <benefit> + - User story: + ```gherkin + As a <role> + I want <feature> + So that <benefit> + ```
105-106: 🧹 Nitpick (assertive)
Fix list numbering in "Adding New Features"
The steps jump from2.back to2.. Update the item after2.to3.and increment all subsequent entries (4.,5., etc.) for a proper sequence.
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
CLAUDE.md (1)
36-40: 🧹 Nitpick (assertive)Use title case for heading and wrap filenames and tool names in backticks
"Important Information" should be title-cased to match other section headings. Also, enclose
.gitignoreand tooling names likePHPCS,PHPStan, andPHPUnitin backticks for clarity:- ## Important information - - Never modify .gitignore file unless I ask you explicitly. - - Never change PHPCS, PHPStan or PHPUnit configuration unless I ask you explicitly. + ## Important Information + - Never modify `.gitignore` file unless explicitly requested. + - Never change `PHPCS`, `PHPStan`, or `PHPUnit` configuration unless explicitly requested.
| 1. Switch to `develop` branch and pull the latest changes | ||
| 2. Create a bugfix branch from `develop` in the format `bugfix/name` | ||
| 3. Fix the issue | ||
| 4. Export configuration changes using `ahoy drush cex -y` | ||
| 5. Add tests to prevent regression | ||
| 6. Commit the code with a message in the format `Verb in past tense with a period at the end.` | ||
| 7. Do not push to remote. | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Clarify bugfix branch workflow regarding pushing to remote
Similarly, step 7 advises not to push to remote. To ensure bug fixes can be reviewed, update it as follows:
- 7. Do not push to remote.
+ 7. Push your bugfix branch to the remote repository and open a pull request against `develop`.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 1. Switch to `develop` branch and pull the latest changes | |
| 2. Create a bugfix branch from `develop` in the format `bugfix/name` | |
| 3. Fix the issue | |
| 4. Export configuration changes using `ahoy drush cex -y` | |
| 5. Add tests to prevent regression | |
| 6. Commit the code with a message in the format `Verb in past tense with a period at the end.` | |
| 7. Do not push to remote. | |
| 1. Switch to `develop` branch and pull the latest changes | |
| 2. Create a bugfix branch from `develop` in the format `bugfix/name` | |
| 3. Fix the issue | |
| 4. Export configuration changes using `ahoy drush cex -y` | |
| 5. Add tests to prevent regression | |
| 6. Commit the code with a message in the format `Verb in past tense with a period at the end.` | |
| 7. Push your bugfix branch to the remote repository and open a pull request against `develop`. |
| 1. Switch to `develop` branch and pull the latest changes | ||
| 2. Create a feature branch from `develop` in the format `feature/name` | ||
| 3. Implement the feature | ||
| 4. Export configuration changes using `ahoy drush cex -y` | ||
| 5. Write appropriate tests | ||
| 6. Run coding standards checks | ||
| 7. Commit the code with a message in the format `Verb in past tense with a period at the end.` | ||
| 8. Do not push to remote. | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Clarify feature branch workflow regarding pushing to remote
Step 8 instructs "Do not push to remote", which may prevent creating a pull request. Consider updating this step to include pushing the feature branch and opening the PR:
- 8. Do not push to remote.
+ 8. Push your feature branch to the remote repository and open a pull request against `develop`.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 1. Switch to `develop` branch and pull the latest changes | |
| 2. Create a feature branch from `develop` in the format `feature/name` | |
| 3. Implement the feature | |
| 4. Export configuration changes using `ahoy drush cex -y` | |
| 5. Write appropriate tests | |
| 6. Run coding standards checks | |
| 7. Commit the code with a message in the format `Verb in past tense with a period at the end.` | |
| 8. Do not push to remote. | |
| 1. Switch to `develop` branch and pull the latest changes | |
| 2. Create a feature branch from `develop` in the format `feature/name` | |
| 3. Implement the feature | |
| 4. Export configuration changes using `ahoy drush cex -y` | |
| 5. Write appropriate tests | |
| 6. Run coding standards checks | |
| 7. Commit the code with a message in the format `Verb in past tense with a period at the end.` | |
| 8. Push your feature branch to the remote repository and open a pull request against `develop`. |
| - Feature: A short description of the test | ||
| - User story: A description of the user story being tested in a format: | ||
| As a <role> | ||
| I want <feature> | ||
| So that <benefit> | ||
| - Scenario: A specific test case | ||
| - Refer to the existing Behat tests to make sure you are following the same structure and conventions. | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Standardize Markdown list formatting for nested test structure
The indentation for the "Feature", "User story", and "Scenario" bullets is inconsistent with the surrounding list. Recommend flattening these to the same level and using proper nesting for sub-points:
- - Feature: A short description of the test
- - User story: A description of the user story being tested in a format:
- As a <role>
- I want <feature>
- So that <benefit>
- - Scenario: A specific test case
- - Refer to the existing Behat tests to make sure you are following the same structure and conventions.
+ - Feature: A short description of the test
+ - User story:
+ As a <role>
+ I want <feature>
+ So that <benefit>
+ - Scenario: A specific test case
+ - Refer to existing Behat tests for consistent structure and conventions.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - Feature: A short description of the test | |
| - User story: A description of the user story being tested in a format: | |
| As a <role> | |
| I want <feature> | |
| So that <benefit> | |
| - Scenario: A specific test case | |
| - Refer to the existing Behat tests to make sure you are following the same structure and conventions. | |
| - Feature: A short description of the test | |
| - User story: | |
| As a <role> | |
| I want <feature> | |
| So that <benefit> | |
| - Scenario: A specific test case | |
| - Refer to existing Behat tests for consistent structure and conventions. |
Summary by CodeRabbit
New Features
Documentation
Tests