07 task expressions#170
Conversation
sisenbrothers-tech
requested review from
ikalinin1,
valfirst and
vkepin
and removed request for
a team
📝 WalkthroughWalkthroughThe changes introduce a new training task (Task_7.story) implementing a complete BDD test scenario using VIVIDUS expressions, along with supporting configuration updates, test data file, and README documentation revision to guide users through expression-driven testing workflows. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@README.md`:
- Line 41: Update the ambiguous sentence "Zip the second Allure report that
contains the comparison result…" in README.md to clarify which report is meant:
either remove "second" to read "the Allure report containing the comparison
result", or explicitly identify it (e.g., "the Allure report for Task X" or "the
second report generated after comparison") so trainees know which report to zip
and upload; change the phrase in the single line that currently contains "Zip
the second Allure report that contains the comparison result" accordingly.
- Line 35: Update the phrasing to use filesystem terminology: change
"message.txt file located in the /data package" to "message.txt file located in
the /data folder (or directory) of your test project" so the instruction for
using the #{loadResource()} VIVIDUS expression to initialize a variable is
consistent with other references; specifically edit the sentence that mentions
#{loadResource()}, message.txt, and /data to replace "package" with "folder" or
"directory".
- Line 25: Replace the typo "test fields" with "text fields" in the README
string "Populate the test fields on the /checkout-step-one.html page" so the
instruction correctly refers to form input fields; update the sentence that
currently reads "Populate the test fields on the /checkout-step-one.html page
using three different VIVIDUS expressions…" to "Populate the text fields…"
ensuring the wording change appears wherever that exact phrase ("Populate the
test fields on the /checkout-step-one.html page") exists.
In `@src/main/resources/properties/configuration.properties`:
- Line 13: configuration.environments currently contains a hardcoded
user-specific value ("saucedemo_Slava"); change it to a clear placeholder like
"saucedemo_YourSurname" (or the generic "saucedemo" if you prefer) so trainees
know to replace it, and if this file is intended as an example also update the
README to state that the property in configuration.properties must be
personalized; locate and edit the configuration.environments entry to implement
the placeholder and align README instructions accordingly.
In `@src/main/resources/story/training/Task_7.story`:
- Around line 33-34: The comparison is over-complicated by using eval on a
resource that likely contains plain text; change the initialization so that
expectedMessage is set to '#{loadResource(data/message.txt)}' and then assert
thankYouMessage equals '#{expectedMessage}' (remove the
'#{eval(expectedMessage)}' usage) unless you intentionally need runtime
expression evaluation inside the file—if so, keep '#{eval(expectedMessage)}'.
- Around line 16-17: The Examples table defines an unused column itemName;
either remove the itemName column/its header and corresponding value ("Sauce
Labs Backpack") from the Examples row, or update the scenario steps in
Task_7.story to consume it (e.g., add a step that uses <itemName> for
verification or logging such as "Then I should see the product name <itemName>
on the item page" or "And log the selected item <itemName>"); locate the
Examples table in Task_7.story and apply one of these changes so every column in
the table is referenced by a step.
- Around line 14-20: The Examples table for the "Scenario Outline: Add item to
the shopping cart" is placed before the scenario steps; move the entire
Examples: block (the header and the pipe-delimited rows for
itemName/itemPageId/addToCartButtonId) so it appears immediately after the
scenario steps (the three "When I click on the element located by id ..."
lines), ensuring the Examples: follows the steps as required by VIVIDUS/Gherkin
syntax.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 66f0a052-ad99-45a3-aaaa-5312831829c3
📒 Files selected for processing (8)
README.mdsrc/main/resources/data/message.txtsrc/main/resources/properties/configuration.propertiessrc/main/resources/properties/environment/saucedemo_Slava/environment.propertiessrc/main/resources/properties/suite/suite.propertiessrc/main/resources/properties/suite/training/suite.propertiessrc/main/resources/steps/ui_common.stepssrc/main/resources/story/training/Task_7.story
|
|
||
| - a. Navigate to the shopping cart and start the checkout process. <br /> | ||
|
|
||
| - b. Populate the test fields on the /checkout-step-one.html page using three different VIVIDUS expressions to generate the following data: a random name or surname, a random string of uppercase and lowercase letters, and a random postal code in the format ABC-12345. <br /> |
There was a problem hiding this comment.
Typo: "test fields" should likely be "text fields".
The instruction mentions "Populate the test fields on the /checkout-step-one.html page" but should probably read "text fields" since it refers to form input fields.
📝 Proposed fix
- - b. Populate the test fields on the /checkout-step-one.html page using three different VIVIDUS expressions to generate the following data: a random name or surname, a random string of uppercase and lowercase letters, and a random postal code in the format ABC-12345. <br />
+ - b. Populate the text fields on the /checkout-step-one.html page using three different VIVIDUS expressions to generate the following data: a random name or surname, a random string of uppercase and lowercase letters, and a random postal code in the format ABC-12345. <br />📝 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.
| - b. Populate the test fields on the /checkout-step-one.html page using three different VIVIDUS expressions to generate the following data: a random name or surname, a random string of uppercase and lowercase letters, and a random postal code in the format ABC-12345. <br /> | |
| - b. Populate the text fields on the /checkout-step-one.html page using three different VIVIDUS expressions to generate the following data: a random name or surname, a random string of uppercase and lowercase letters, and a random postal code in the format ABC-12345. <br /> |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` at line 25, Replace the typo "test fields" with "text fields" in
the README string "Populate the test fields on the /checkout-step-one.html page"
so the instruction correctly refers to form input fields; update the sentence
that currently reads "Populate the test fields on the /checkout-step-one.html
page using three different VIVIDUS expressions…" to "Populate the text fields…"
ensuring the wording change appears wherever that exact phrase ("Populate the
test fields on the /checkout-step-one.html page") exists.
|
|
||
| - b. After clicking the Finish button on the /checkout-complete.html page, save the text of the "Thank you" message to a variable. <br /> | ||
|
|
||
| - c. Use the #{loadResource()} VIVIDUS expression to initialize another variable that holds the contents of the message.txt file located in the /data package of your test project. <br /> |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Minor terminology inconsistency: "package" vs "folder/directory".
The instruction refers to the "message.txt file located in the /data package" but uses "folder" terminology elsewhere in the documentation (line 7 uses "package" for Java packages, line 9 doesn't specify). For clarity and consistency with file system terminology, consider using "data folder" or "data directory" instead of "data package" when referring to the file system location.
📝 Suggested refinement
- - c. Use the #{loadResource()} VIVIDUS expression to initialize another variable that holds the contents of the message.txt file located in the /data package of your test project. <br />
+ - c. Use the #{loadResource()} VIVIDUS expression to initialize another variable that holds the contents of the message.txt file located in the /data folder of your test project. <br />📝 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.
| - c. Use the #{loadResource()} VIVIDUS expression to initialize another variable that holds the contents of the message.txt file located in the /data package of your test project. <br /> | |
| - c. Use the #{loadResource()} VIVIDUS expression to initialize another variable that holds the contents of the message.txt file located in the /data folder of your test project. <br /> |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` at line 35, Update the phrasing to use filesystem terminology:
change "message.txt file located in the /data package" to "message.txt file
located in the /data folder (or directory) of your test project" so the
instruction for using the #{loadResource()} VIVIDUS expression to initialize a
variable is consistent with other references; specifically edit the sentence
that mentions #{loadResource()}, message.txt, and /data to replace "package"
with "folder" or "directory".
|
|
||
| 1. Run the resulting story on your local machine using the configuration set in the suite.training file. If needed, you can adjust the execution scope by modifying the `overriding.properties` file. <br /> | ||
|
|
||
| 1. Zip the second Allure report that contains the comparison result, and then upload the zipped file to the designated practical task page in the course. Your mentor will review it once you submit all the tasks. |
There was a problem hiding this comment.
Ambiguous reference: "second Allure report".
The instruction mentions "Zip the second Allure report that contains the comparison result" but doesn't clarify what the "first" report was or why this is specifically the "second" one. This could confuse trainees who are following the instructions sequentially.
Consider clarifying with one of these approaches:
- Remove "second" and just say "the Allure report"
- Explain what makes this the "second" report (e.g., "second in the series of tasks")
- Reference it by content: "the Allure report containing Task 7 results"
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` at line 41, Update the ambiguous sentence "Zip the second Allure
report that contains the comparison result…" in README.md to clarify which
report is meant: either remove "second" to read "the Allure report containing
the comparison result", or explicitly identify it (e.g., "the Allure report for
Task X" or "the second report generated after comparison") so trainees know
which report to zip and upload; change the phrase in the single line that
currently contains "Zip the second Allure report that contains the comparison
result" accordingly.
| # pick up environment related properties from 'saucedemo' environment folder: | ||
|
|
||
| configuration.environments=saucedemo | ||
| configuration.environments=saucedemo_Slava |
There was a problem hiding this comment.
Inconsistency: Hardcoded user-specific environment contradicts README instructions.
The environment name is hardcoded to saucedemo_Slava, but line 7 of the README instructs users to rename the environment package to saucedemo_{yourSurname} and update this configuration file accordingly. This creates a conflict where the configuration file already contains a specific user's surname instead of a generic template or the user's own surname.
Consider one of the following approaches:
- Leave the environment as
saucedemo(generic) so each trainee can personalize it as instructed - Update the README to clarify that this is an example implementation
- Use a placeholder like
saucedemo_YourSurnamethat makes it obvious users need to change it
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/main/resources/properties/configuration.properties` at line 13,
configuration.environments currently contains a hardcoded user-specific value
("saucedemo_Slava"); change it to a clear placeholder like
"saucedemo_YourSurname" (or the generic "saucedemo" if you prefer) so trainees
know to replace it, and if this file is intended as an example also update the
README to state that the property in configuration.properties must be
personalized; locate and edit the configuration.environments entry to implement
the placeholder and align README instructions accordingly.
| Scenario Outline: Add item to the shopping cart | ||
| Examples: | ||
| | itemName | itemPageId | addToCartButtonId | | ||
| | Sauce Labs Backpack | item_4_title_link | add-to-cart-sauce-labs-backpack | | ||
| When I click on the element located by id '<itemPageId>' | ||
| And I click on the element located by id '<addToCartButtonId>' | ||
| And I click on the element located by id 'shopping_cart_container' |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
VIVIDUS BDD Scenario Outline Examples placement syntax
💡 Result:
In VIVIDUS (JBehave/Gherkin stories), an Examples: table is placed directly under the last step of the Scenario Outline: (i.e., it belongs to that outline). The table is pipe-delimited, and the placeholder names used in steps match the table headers. [1]
Scenario Outline: Verify something with <data>
Given I do something with <data>
Then I get <result>
Examples:
|data |result|
|foo |ok |
|bar |fail |VIVIDUS also supports putting meta per Examples row by adding a Meta: column in the Examples table (useful for filtering which rows execute). [2]
Scenario Outline: My scenario
...
Examples:
|Meta: |data |
|@environment dev |foo |
|@environment qa |bar |(An “Examples table” in VIVIDUS is the standard header row + value rows structure shown above.) [3]
Sources: [1] JBehave “Story Syntax” (Gherkin Scenario Outline + Examples placement) (jbehave.org), [2] VIVIDUS “Tests Configuration” (Examples row meta / filtering) (docs.vividus.dev), [3] VIVIDUS Glossary “ExamplesTable” (docs.vividus.dev)
Citations:
- 1: https://jbehave.org/reference/latest/story-syntax.html
- 2: https://docs.vividus.dev/vividus/latest/configuration/tests-configuration.html?utm_source=openai
- 3: https://docs.vividus.dev/vividus/latest/glossary.html?utm_source=openai
Scenario Outline Examples must be placed after the scenario steps.
In VIVIDUS (based on Gherkin/JBehave), the Examples: table should appear directly after the scenario steps, not before. The current structure has Examples on lines 15-17 before the steps on lines 18-20, which violates the syntax specification.
🔧 Move Examples after steps
Scenario Outline: Add item to the shopping cart
-Examples:
-| itemName | itemPageId | addToCartButtonId |
-| Sauce Labs Backpack | item_4_title_link | add-to-cart-sauce-labs-backpack |
When I click on the element located by id '<itemPageId>'
And I click on the element located by id '<addToCartButtonId>'
And I click on the element located by id 'shopping_cart_container'
+Examples:
+| itemName | itemPageId | addToCartButtonId |
+| Sauce Labs Backpack | item_4_title_link | add-to-cart-sauce-labs-backpack |📝 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.
| Scenario Outline: Add item to the shopping cart | |
| Examples: | |
| | itemName | itemPageId | addToCartButtonId | | |
| | Sauce Labs Backpack | item_4_title_link | add-to-cart-sauce-labs-backpack | | |
| When I click on the element located by id '<itemPageId>' | |
| And I click on the element located by id '<addToCartButtonId>' | |
| And I click on the element located by id 'shopping_cart_container' | |
| Scenario Outline: Add item to the shopping cart | |
| When I click on the element located by id '<itemPageId>' | |
| And I click on the element located by id '<addToCartButtonId>' | |
| And I click on the element located by id 'shopping_cart_container' | |
| Examples: | |
| | itemName | itemPageId | addToCartButtonId | | |
| | Sauce Labs Backpack | item_4_title_link | add-to-cart-sauce-labs-backpack | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/main/resources/story/training/Task_7.story` around lines 14 - 20, The
Examples table for the "Scenario Outline: Add item to the shopping cart" is
placed before the scenario steps; move the entire Examples: block (the header
and the pipe-delimited rows for itemName/itemPageId/addToCartButtonId) so it
appears immediately after the scenario steps (the three "When I click on the
element located by id ..." lines), ensuring the Examples: follows the steps as
required by VIVIDUS/Gherkin syntax.
| | itemName | itemPageId | addToCartButtonId | | ||
| | Sauce Labs Backpack | item_4_title_link | add-to-cart-sauce-labs-backpack | |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Unused column itemName in Examples table.
The itemName column is defined in the Examples table but is never referenced in the scenario steps using <itemName>. Consider removing it if not needed, or adding a step that uses it (e.g., for verification or logging purposes).
♻️ Option 1: Remove unused column
Examples:
-| itemName | itemPageId | addToCartButtonId |
-| Sauce Labs Backpack | item_4_title_link | add-to-cart-sauce-labs-backpack |
+| itemPageId | addToCartButtonId |
+| item_4_title_link | add-to-cart-sauce-labs-backpack |📝 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.
| | itemName | itemPageId | addToCartButtonId | | |
| | Sauce Labs Backpack | item_4_title_link | add-to-cart-sauce-labs-backpack | | |
| | itemPageId | addToCartButtonId | | |
| | item_4_title_link | add-to-cart-sauce-labs-backpack | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/main/resources/story/training/Task_7.story` around lines 16 - 17, The
Examples table defines an unused column itemName; either remove the itemName
column/its header and corresponding value ("Sauce Labs Backpack") from the
Examples row, or update the scenario steps in Task_7.story to consume it (e.g.,
add a step that uses <itemName> for verification or logging such as "Then I
should see the product name <itemName> on the item page" or "And log the
selected item <itemName>"); locate the Examples table in Task_7.story and apply
one of these changes so every column in the table is referenced by a step.
| And I initialize the variable 'expectedMessage' with the value '#{loadResource(data/message.txt)}' | ||
| Then the variable 'thankYouMessage' is equal to '#{eval(expectedMessage)}' |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider simplifying the expected message comparison.
If data/message.txt contains only plain text ("Thank you for your order!"), the #{eval(expectedMessage)} wrapper may be unnecessary. The eval expression is typically used when the loaded resource itself contains VIVIDUS expressions that need evaluation.
If the file contains no expressions, you could simplify the assertion:
-Then the variable 'thankYouMessage' is equal to '#{eval(expectedMessage)}'
+Then the variable 'thankYouMessage' is equal to '${expectedMessage}'However, if the intent is to support dynamic expressions in the message file in the future, the current approach provides flexibility.
📝 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.
| And I initialize the variable 'expectedMessage' with the value '#{loadResource(data/message.txt)}' | |
| Then the variable 'thankYouMessage' is equal to '#{eval(expectedMessage)}' | |
| And I initialize the variable 'expectedMessage' with the value '#{loadResource(data/message.txt)}' | |
| Then the variable 'thankYouMessage' is equal to '${expectedMessage}' |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/main/resources/story/training/Task_7.story` around lines 33 - 34, The
comparison is over-complicated by using eval on a resource that likely contains
plain text; change the initialization so that expectedMessage is set to
'#{loadResource(data/message.txt)}' and then assert thankYouMessage equals
'#{expectedMessage}' (remove the '#{eval(expectedMessage)}' usage) unless you
intentionally need runtime expression evaluation inside the file—if so, keep
'#{eval(expectedMessage)}'.
2 participants
test
Summary by CodeRabbit
Documentation
New Features
Chores