8000 [#285] Updated FieldTrait. by skipper-vp · Pull Request #351 · drevops/behat-steps · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[#285] Updated FieldTrait. #351

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

Merged
merged 2 commits into from
Apr 9, 2025

Conversation

skipper-vp
Copy link
Contributor
@skipper-vp skipper-vp commented Apr 9, 2025

Closes #285

Updated FieldTrait.

Summary by CodeRabbit

  • Documentation

    • Updated migration guidance with clearer, more explicit language for describing field and keyboard interactions.
  • Refactor

    • Standardized phrasing for field existence, non-existence, and state checks to ensure consistency.
    • Revised language for keyboard actions to improve clarity.
    • Removed deprecated WYSIWYG handling functionality.
  • Tests

    • Aligned test scenarios and examples with the updated step definitions for a uniform user experience.
    • Removed tests related to WYSIWYG functionality.

Copy link
coderabbitai bot commented Apr 9, 2025

Walkthrough

The changes standardize and update step definitions from version 2 to version 3. In the migration map, revised phrasing for field and keyboard assertions replaces less clear language and removes redundant steps. The trait in the source code now uses updated documentation and method signatures (e.g., renaming a parameter from $disabled to $enabled_or_disabled) while removing combined assertion methods. The corresponding Gherkin steps and Behat feature scenarios are updated accordingly to maintain consistency in how field existence, non-existence, and state assertions are expressed.

Changes

File(s) Change Summary
MIGRATION.md, steps.md, tests/behat/features/field.feature Updated Gherkin step definitions and feature scenarios for field assertions: phrases changed to “the field :name should exist/should not exist” and “the field :name should be :enabled_or_disabled,” removal of combined assertion steps, and reformatting of LinkTrait steps for improved consistency.
src/FieldTrait.php Updated documentation and method signatures for field assertions; changed parameter name from $field_name to $name, removed methods for combined existence and state assertions, and revised color field methods to align with the new phrasing.
src/WysiwygTrait.php, tests/behat/bootstrap/FeatureContext.php, tests/behat/features/wysiwyg.feature Removed the WysiwygTrait and its associated methods from the FeatureContext, eliminating WYSIWYG field handling functionality. The wysiwyg.feature file was deleted, which contained scenarios for testing WYSIWYG editor functionality.

Possibly related PRs

  • [#290] Updated LinkTrait. #349: Updates in FieldTrait step definitions here align with similar modifications in LinkTrait, reflecting parallel changes for clearer and more consistent assertion phrasing.

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9d61908 and 5e628be.

📒 Files selected for processing (7)
  • MIGRATION.md (2 hunks)
  • src/FieldTrait.php (5 hunks)
  • src/WysiwygTrait.php (0 hunks)
  • steps.md (1 hunks)
  • tests/behat/bootstrap/FeatureContext.php (0 hunks)
  • tests/behat/features/field.feature (4 hunks)
  • tests/behat/features/wysiwyg.feature (0 hunks)
💤 Files with no reviewable changes (3)
  • tests/behat/features/wysiwyg.feature
  • tests/behat/bootstrap/FeatureContext.php
  • src/WysiwygTrait.php
🧰 Additional context used
🪛 LanguageTool
MIGRATION.md

[grammar] ~31-~31: There is an agreement error between ‘see’ and ‘field’. Insert ‘a(n)’ or change the noun to plural.
Context: ... | | Then I see field :name ...

(PRP_VB_NN)

🪛 markdownlint-cli2 (0.17.2)
MIGRATION.md

39-39: Table pipe style
Expected: leading_and_trailing; Actual: leading_only; Missing trailing pipe

(MD055, table-pipe-style)


39-39: Table column count
Expected: 2; Actual: 1; Too few cells, row will be missing data

(MD056, table-column-count)

🪛 GitHub Check: codecov/patch
src/FieldTrait.php

[warning] 41-41: src/FieldTrait.php#L41
Added line #L41 was not covered by tests


[warning] 66-66: src/FieldTrait.php#L66
Added line #L66 was not covered by tests


[warning] 86-86: src/FieldTrait.php#L86
Added line #L86 was not covered by tests


[warning] 89-89: src/FieldTrait.php#L89
Added line #L89 was not covered by tests


[warning] 151-151: src/FieldTrait.php#L151
Added line #L151 was not covered by tests


[warning] 166-166: src/FieldTrait.php#L166
Added line #L166 was not covered by tests


[warning] 174-175: src/FieldTrait.php#L174-L175
Added lines #L174 - L175 were not covered by tests


[warning] 177-177: src/FieldTrait.php#L177
Added line #L177 was not covered by tests

🔇 Additional comments (17)
steps.md (3)

398-404: Improved step definition clarity.

The update from @Then I see field :name to @Then the field :name should exist follows better BDD conventions with more explicit assertion language. This makes the steps clearer and more consistent with other traits.


409-415: Consistent assertion syntax for field non-existence.

The update from @Then I don't see field :name to @Then the field :name should not exist follows the same pattern of using explicit "should" assertions, making the test language more consistent.


420-428: Enhanced field state assertion with clearer parameter naming.

The change from @Then field :name is :disabled on the page to @Then the field :name should be :enabled_or_disabled improves clarity by:

  1. Using consistent "should be" assertion syntax
  2. Renaming the parameter to better reflect that it can handle both enabled and disabled states
  3. Providing examples for all use cases including enabled and disabled states
MIGRATION.md (2)

31-38: Comprehensive migration path with clear mappings.

The migration map has been properly updated to reflect the changes to the field-related step definitions, with appropriate removals of deprecated steps and clearer phrasing for the remaining steps. This provides users with a clear migration path from v2 to v3.

The addition of WYSIWYG-related step mapping in line 38 is particularly valuable as it documents the integration of functionality previously available in WysiwygTrait.

🧰 Tools
🪛 LanguageTool

[grammar] ~31-~31: There is an agreement error between ‘see’ and ‘field’. Insert ‘a(n)’ or change the noun to plural.
Context: ... | | Then I see field :name ...

(PRP_VB_NN)


53-55: Standardized link assertions.

The link assertion steps have been updated to use consistent phrasing with the new field assertion style, providing uniformity across the library.

src/FieldTrait.php (6)

21-22: Proper trait inclusion.

Including KeyboardTrait directly in FieldTrait ensures the necessary keyboard-related methods are available for field interactions, especially useful for the new WYSIWYG functionality.


23-47: Updated field existence assertion with improved documentation.

The method signature and documentation have been properly updated to align with the new step definition phrasing. The implementation correctly checks for fields by ID, name, label, or value and provides a clear error message.

🧰 Tools
🪛 GitHub Check: codecov/patch

[warning] 41-41: src/FieldTrait.php#L41
Added line #L41 was not covered by tests


49-68: Improved field non-existence assertion.

The method has been updated with a more descriptive parameter name and better error messaging that matches the new step definition language.

🧰 Tools
🪛 GitHub Check: codecov/patch

[warning] 66-66: src/FieldTrait.php#L66
Added line #L66 was not covered by tests


70-91: Enhanced field state assertion with better parameter naming.

The change from $disabled to $enabled_or_disabled makes the parameter more descriptive of its purpose, accepting values like "enabled", "disabled", "not enabled", etc. The validation logic correctly handles both positive and negative cases.

🧰 Tools
🪛 GitHub Check: codecov/patch

[warning] 86-86: src/FieldTrait.php#L86
Added line #L86 was not covered by tests


[warning] 89-89: src/FieldTrait.php#L89
Added line #L89 was not covered by tests


93-134: Standardized color field methods with clearer documentation.

The methods for handling color fields have been updated with more consistent language in their documentation, making them align with the rest of the trait.


136-204:

✅ Verification successful

Well-implemented WYSIWYG field support.

This new method provides comprehensive support for filling WYSIWYG fields, handling both CKEditor 4 and 5, with proper fallback for non-JS drivers. The implementation includes:

  1. Proper error handling for field not found or empty ID
  2. Driver capability detection
  3. Editor-specific implementations
  4. Helper method for fixing string arguments

Some lines are flagged by code coverage tools as not covered by tests, but the feature file includes both API and JavaScript tests for this functionality.


🏁 Script executed:

#!/bin/bash
# Check if there are any other WYSIWYG editors used in the codebase
# that might need support in this implementation

echo "Searching for WYSIWYG editor references in the codebase..."
rg -i "wysiwyg|editor|ckeditor|tinymce|quill" --type php

Length of output: 2180


Approved: Robust WYSIWYG Field Support Implementation

The implementation in src/FieldTrait.php efficiently manages WYSIWYG fields by handling both CKEditor 4 and CKEditor 5 scenarios—with graceful fallback for non-JS drivers. The code includes appropriate error handling (e.g., when a field is not found or has an empty ID), proper driver capability checks, and a helper method that correctly fixes string arguments. Our review of the codebase confirms that no additional WYSIWYG editors (such as TinyMCE or Quill) are in use that would require integration, and existing tests (both API and JavaScript) are addressing this functionality despite some minor code coverage flags.

  • Error handling for missing fields or empty IDs is well-implemented.
  • Distinct logic for CKEditor 4 versus CKEditor 5 is clear and effective.
  • The helper method for fixing step arguments is precise and maintains code clarity.

Great work—this implementation meets our requirements without any remaining concerns.

🧰 Tools
🪛 GitHub Check: codecov/patch

[warning] 151-151: src/FieldTrait.php#L151
Added line #L151 was not covered by tests


[warning] 166-166: src/FieldTrait.php#L166
Added line #L166 was not covered by tests


[warning] 174-175: src/FieldTrait.php#L174-L175
Added lines #L174 - L175 were not covered by tests


[warning] 177-177: src/FieldTrait.php#L177
Added line #L177 was not covered by tests

tests/behat/features/field.feature (6)

3-8: Updated field existence scenario with new syntax.

The scenario has been properly updated to use the new "should exist" syntax that matches the implementation in FieldTrait.


9-13: Updated field non-existence scenario with consistent syntax.

The non-existence scenario now uses the more explicit "should not exist" phrasing that aligns with the implementation.


14-25: Standardized field existence scenario outline.

The scenario outline has been updated to use "should exist" and "should not exist" phrasing with appropriate examples covering both positive and negative cases.


26-38: Comprehensive field state testing.

The scenario has been renamed to reflect that it tests both enabled and disabled states, and the examples have been updated to use the new parameter name enabled_or_disabled. This provides complete test coverage for the updated method.


123-134: New test for WYSIWYG field functionality.

This scenario properly tests the new WYSIWYG field support added to FieldTrait, ensuring it works correctly with the standard API driver.


135-146: JavaScript-specific test for WYSIWYG functionality.

The additional scenario with the @javascript tag ensures the WYSIWYG functionality works correctly with JavaScript-enabled drivers, providing more complete test coverage for the new feature.

✨ Finishing Touches
  • 📝 Generate Docstrings

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai plan to trigger planning for file edits and PR creation.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
codecov bot commented Apr 9, 2025

Codecov Report

Attention: Patch coverage is 76.92308% with 9 lines in your changes missing coverage. Please review.

Project coverage is 79.55%. Comparing base (9d61908) to head (5e628be).
Report is 1 commits behind head on 3.x.

Files with missing lines Patch % Lines
src/FieldTrait.php 76.92% 9 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##              3.x     #351      +/-   ##
==========================================
- Coverage   79.64%   79.55%   -0.10%     
==========================================
  Files          31       30       -1     
  Lines        1474     1467       -7     
==========================================
- Hits         1174     1167       -7     
  Misses        300      300              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@AlexSkrypnyk AlexSkrypnyk requested a review from Copilot April 9, 2025 03:23
@AlexSkrypnyk
Copy link
Member

@coderabbitai review

Copy link
@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot reviewed 2 out of 4 changed files in this pull request and generated no comments.

Files not reviewed (2)
  • src/FieldTrait.php: Language not supported
  • tests/behat/features/field.feature: Language not supported
Comments suppressed due to low confidence (2)

steps.md:400

  • [nitpick] Consider using consistent step definition phrasing across existence checks; verify that the term 'the field' aligns with the naming conventions used in other step definitions.
@Then the field :name should exist

MIGRATION.md:35

  • [nitpick] The updated field state mapping is now generic; consider clarifying in the documentation how specific states (e.g., 'disabled', 'enabled') are represented to avoid ambiguity.
Then field :name is :disabled on the page
→
Then the field :name should be :state

Copy link
coderabbitai bot commented Apr 9, 2025
✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link
@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
MIGRATION.md (1)

38-38: Fix missing table formatting

The table row is missing the trailing pipe character, which is causing markdown formatting issues according to static analysis.

-| &nbsp;
+| &nbsp;                                                                                                                       |
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)

38-38: Table pipe style
Expected: leading_and_trailing; Actual: leading_only; Missing trailing pipe

(MD055, table-pipe-style)


38-38: Table column count
Expected: 2; Actual: 1; Too few cells, row will be missing data

(MD056, table-column-count)

tests/behat/features/field.feature (1)

82-93: Duplicate error test scenario

This scenario appears to be testing the same condition as the previous one, just using the field ID instead of the field label. Consider adding a comment to clarify the difference between these two scenarios or consolidating them.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9d61908 and 43bad6a.

📒 Files selected for processing (4)
  • MIGRATION.md (2 hunks)
  • src/FieldTrait.php (4 hunks)
  • steps.md (1 hunks)
  • tests/behat/features/field.feature (4 hunks)
🧰 Additional context used
🪛 LanguageTool
MIGRATION.md

[grammar] ~31-~31: There is an agreement error between ‘see’ and ‘field’. Insert ‘a(n)’ or change the noun to plural.
Context: ... | | Then I see field :name ...

(PRP_VB_NN)

🪛 markdownlint-cli2 (0.17.2)
MIGRATION.md

38-38: Table pipe style
Expected: leading_and_trailing; Actual: leading_only; Missing trailing pipe

(MD055, table-pipe-style)


38-38: Table column count
Expected: 2; Actual: 1; Too few cells, row will be missing data

(MD056, table-column-count)

🔇 Additional comments (24)
steps.md (6)

400-401: Well-structured change to field existence assertion phrase

The change from "I see field" to "the field should exist" is a good improvement that aligns with BDD best practices by using more declarative phrasing rather than imperative.


404-406: Consistently updated examples to match new assertion style

The examples properly reflect the updated step definition syntax, maintaining consistency throughout the documentation.


411-412: Improvement to field non-existence assertion phrase

Similar to the existence assertion, this change to "should not exist" follows the same pattern of making the step definition more declarative and consistent.


415-417: Examples correctly updated for non-existence assertion

The examples properly mirror the updated step definition, maintaining documentation consistency.


422-423: Better state assertion with improved clarity

The change from "field is disabled" to "field should be state" makes the assertion more versatile and descriptive, allowing for various states beyond just "disabled".


426-430: Comprehensive examples for different state assertions

The examples now clearly demonstrate multiple state conditions ("disabled", "enabled", "not enabled"), which helps users understand how to use this assertion in different scenarios.

MIGRATION.md (2)

31-37: Comprehensive migration map for field-related steps

The migration map correctly documents all the changes from v2 to v3 for the FieldTrait, including the removed steps and the renamed states. This will be very helpful for users upgrading from v2 to v3 of the library.

🧰 Tools
🪛 LanguageTool

[grammar] ~31-~31: There is an agreement error between ‘see’ and ‘field’. Insert ‘a(n)’ or change the noun to plural.
Context: ... | | Then I see field :name ...

(PRP_VB_NN)


52-54: Consistent terminology in link trait migration

The LinkTrait migration entries now use consistent terminology with the rest of the migration map, focusing on "should be" rather than "is" phrases.

src/FieldTrait.php (6)

23-25: Updated documentation comments to reflect new assertion style

Documentation now matches the step definition changes, improving consistency between code and documentation.

Also applies to: 27-28


49-51: Consistent documentation update for not-exists assertions

The documentation for the non-existence assertion method follows the same pattern as the existence assertion, maintaining a consistent style throughout the trait.

Also applies to: 53-54


70-74: Improved documentation for state assertions

The documentation now clearly shows different state examples, making it more obvious how to use this method for both positive and negative assertions about field states.

Also applies to: 76-77


78-87: Method parameter name change from $disabled to $state

The parameter renaming from $disabled to $state makes the method more flexible and better reflects its purpose of handling various states. The implementation correctly uses the new parameter name in its conditions.


93-94: Added alias annotation for color field method

Adding the alternative annotation pattern maintains backward compatibility while introducing the new, more descriptive step definition.


113-114: Updated annotation for color field assertion

The color field assertion annotation now follows the same pattern as other assertions in the trait, improving consistency.

tests/behat/features/field.feature (10)

6-8: Updated test scenario to use new step definition syntax

The test scenario now correctly uses the new "should exist" syntax, ensuring that the tests validate the updated implementation.


12-13: Updated non-existence assertion in test

The test for field non-existence now uses the updated step definition syntax.


17-25: Updated scenario outline for field existence

The scenario outline now uses the new syntax with examples that properly test both existence and non-existence conditions.


29-38: Updated scenario outline for field state

The scenario outline for testing field states now uses the more flexible "should be" syntax with examples for both enabled and disabled states.


42-45: Updated assertions for color fields

The color field assertions now use the new syntax, maintaining consistency with other field-related assertions.


49-52: Added test for alternative color field step definition

A new test scenario has been added to test the alternative step definition for filling in color fields, ensuring both annotation patterns work correctly.


54-65: Updated error test scenario for field existence

The test scenario for verifying error messages when field existence fails has been updated to use the new syntax, ensuring that error handling still works correctly.


68-79: Updated error test scenario for field non-existence

Similar to the existence error test, this scenario has been updated to use the new syntax while verifying the same error message is produced.


96-108: Updated state error test scenario

The test for verifying error messages when field state assertions fail has been updated to use the new syntax, ensuring error handling works correctly with the renamed parameter.


110-121: Updated negative assertion test for field state

The final test scenario for field state negative assertion has been updated to use the new syntax while ensuring the error message is still correctly produced.

Copy link
Member
@AlexSkrypnyk AlexSkrypnyk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@skipper-vp
Thank you for working on this.

Please my comments and update.

Also, please bring here the WYSIWYG steps.

Thank you

@@ -151,7 +110,7 @@ public function fillColorField(string $field, ?string $value = NULL): mixed {
/**
* Asserts that a color field has a value.
*
* @Then /^color field "(?P<field>(?:[^"]|\\")*)" value is "(?P<value>(?:[^"]|\\")*)"$/
* @Then /^the color field "(?P<field>(?:[^"]|\\")*)" should have the value "(?P<value>(?:[^"]|\\")*)"$/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please replace the regexp according to #134 (comment) 1.a

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replaced with @Then the color field :field should have the value :value

/**
* Fills value for color field.
*
* @When /^(?:|I )fill color in "(?P<field>(?:[^"]|\\")*)" with "(?P<value>(?:[^"]|\\")*)"$/
* @When /^(?:|I )fill color in "(?P<value>(?:[^"]|\\")*)" for "(?P<field>(?:[^"]|\\")*)"$/
* @When /^(?:|I )fill in the color field "(?P<field>(?:[^"]|\\")*)" with the value "(?P<value>(?:[^"]|\\")*)"$/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please replace the regexp according to #134 (comment) 1.a

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replaced with
* @When I fill color in :field with :value
* @When I fill in the color field :field with the value :value

* @endcode
*
* @Then I don't see field :name
* @Then the field :name should not exist
*/
public function fieldAssertNotExists(string $field_name): void {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please update the arg name as per please replace the regexp according to #134 (comment) 1.d

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated with public function fieldAssertNotExists(string $name): void {

*/
public function fieldAssertState(string $field_name, string $disabled): void {
public function fieldAssertState(string $field_name, string $state): void {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please update the arg name according to #134 (comment) 1.d

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated with public function fieldAssertState(string $name, string $enabled_or_disabled): void {

@AlexSkrypnyk AlexSkrypnyk added the PR: Requires more work Pull request was reviewed and reviver(s) asked to work further on the pull request label Apr 9, 2025
* @endcode
*
* @Then field :name is :disabled on the page
* @Then the field :name should be :state
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please update this to

@Then the field :name should be :enabled_or_disabled

and then also please update it everywhere

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been updated

@skipper-vp skipper-vp requested a review from AlexSkrypnyk April 9, 2025 06:00
@AlexSkrypnyk
Copy link
Member

@coderabbitai full review

Copy link
coderabbitai bot commented Apr 9, 2025
✅ Actions performed

Full review triggered.

@AlexSkrypnyk AlexSkrypnyk merged commit a521ad3 into drevops:3.x Apr 9, 2025
3 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: Requires more work Pull request was reviewed and reviver(s) asked to work further on the pull request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0