diff --git a/src/content/docs/project/tests/bdd-test-case-editor.md b/src/content/docs/project/tests/bdd-test-case-editor.md index 016d42fe..97fefb37 100644 --- a/src/content/docs/project/tests/bdd-test-case-editor.md +++ b/src/content/docs/project/tests/bdd-test-case-editor.md @@ -1,5 +1,5 @@ --- -title: BDD Test Case Editor +title: BDD Project description: Learn how to write and manage BDD test scenarios using Testomat.io. This guide explores creating Gherkin-based tests, editing feature files, and using BDD workflows to improve collaboration, traceability, and test automation. type: article url: https://docs.testomat.io/project/bdd_editor @@ -10,89 +10,227 @@ head: content: test design, test cases, test management, test automation, testing techniques, Testomat.io, BDD, Gherkin, Cucumber, test scenarios, project workflow, software testing --- -## Test Case Editor +A BDD project stores tests as Gherkin scenarios. Each suite is a `.feature` file, and each test is a scenario inside that file. A BDD project is a good fit when you: -Test Case Editor is a dynamic interface, designed to accommodate the diverse requirements of test case formulation. Through this platform, testers wield the power to architect meticulously structured test scenarios, encompassing a range of variables, actions, expected results, and potential outcomes. +- write scenarios together with business, development, and QA teams, +- use a Cucumber-based automation framework, +- want your test scenarios to be closely connected to automation, +- want to describe the starting state and expected result for each scenario. -Regarding test case creation, Testomat.io offers two distinct editor types: the **Classical** Editor and the **BDD** (Behavior-Driven Development) Editor. Each caters to different testing methodologies and user preferences, enabling testers to choose the approach that best aligns with their needs. +![A folder holds feature files, a feature file holds scenarios](./images/bdd-projects/bdd-project-structure.png) -Let's have a look at **BDD** Editor. +:::note -## BDD Editor Review +A project is either Classical or BDD, and the type cannot be changed after creation. To move from Classical to BDD, you create a new BDD project and transfer the tests - manually, or with the Transform Project to BDD AI agent. There is no supported way to move from BDD to Classical. See [Classical vs BDD](https://docs.testomat.io/project/tests/classical-vs-bdd) and [AI-Agents](https://docs.testomat.io/advanced/ai-powered-features/ai-agents). -As you embark on the journey of crafting and refining BDD scenarios, this innovative platform empowers you to shape narratives into meticulously executable tests. At its core, the BDD Editor encapsulates the essence of collaboration, precision, and agility, delivering a comprehensive solution for modern testing workflows. Here, you'll create user stories, scenarios, and document expected behaviors with an eloquence that bridges the gap between technical and non-technical stakeholders. +::: -**Feature File Editor** +## Feature Files, Scenarios, and Folders -In the context of BDD, the Feature File serves as the canvas upon which your software's behavior is painted. +In a BDD project, each suite is a `.feature` file. The scenarios inside the file are the tests. -Let's see what we have here! +![Test overview in the BDD editor of Testomat.io UI](./images/bdd-projects/1-test-overview.png) -![Edit Feature File](./images/BDD_edit_suite.png) +A feature file cannot contain another feature file, so a suite cannot contain other suites. Use folders to group feature files. Tests are organised like files in your code, so a manual test can become automated without moving it. See [Suites and Folders](https://docs.testomat.io/project/tests/other-features-for-test-case-design/#suites-and-folders) to learn more. -1. **Editing Area** – Displays the Feature File with Given/When/Then steps. -2. **Attachments** – Upload supporting files via the attachments dialog. -3. **Extra Menu** – Access additional options. -4. **Autocomplete Steps** – Toggle step suggestions. -5. **Autocomplete Snippets** – Toggle snippet suggestions. -6. **Autocomplete Tags** – Toggle tag suggestions. -7. **Fullscreen** – Enter a distraction-free workspace. -8. **Format** – Structure Scenarios into Gherkin format. -9. **Set Labels** – Assign existing labels or create custom fields. -10. **Save** – Save your work. -11. **Go Back** – Return to the previous screen. -12. **Close** – Exit the editor. +## Gherkin Syntax -**Scenarios Editor** +BDD scenarios use Gherkin keywords such as `Given`, `When`, `Then`, and `And`. The BDD editor checks the Gherkin syntax as you type. If you misspell a keyword or miss a required line, the scenario cannot be saved as a valid test. -Beyond Feature Files lies the individual tests. Here, the BDD Editor grants you the ability to sculpt scenarios with precision, breaking down user behaviors into granular steps and verifiable outcomes. Each test becomes a symphony of detail, harmonizing the user's journey with the software's responses. By editing separate tests within the BDD Editor, you orchestrate complex interactions, validations, and expectations. +| Keyword | Description | +| --- | --- | +| **Given** | The starting state | +| **When** | An action | +| **Then** | The expected result | +| **And** | Another step added to the previous one | -![Edit scenario](./images/BDD_edit_test.png) +For example: -1. **Editing Area** – Displays Scenarios with Given/When/Then steps. -2. **Attachments** – Upload supporting files via the attachments dialog. -3. **Extra Menu** – Access additional options. -4. **Autocomplete Steps** – Toggle step suggestions. -5. **Autocomplete Snippets** – Toggle snippet suggestions. -6. **Autocomplete Tags** – Toggle tag suggestions. -7. **Fullscreen** – Enter a distraction-free workspace. -8. **Set Labels** – Assign existing labels or create custom fields. -9. **Change State** – Update the test state (e.g., manual to automated). -10. **Save** – Save your work. -11. **Go Back** – Return to the previous screen. -12. **Close** – Exit the editor. +```gherkin +Feature: User Authentication +Scenario: Successful login with valid credentials -**Saving changes in the feature file as a draft** +Given the user is on the Testomat.io login page +When the user enters valid credentials +And the user clicks the 'Sign In' button +Then the user should be redirected to the Project Dashboard +And a "Welcome" message should be displayed +``` +You can keep an unfinished scenario as a draft. See [Drafts for unfinished scenarios](#drafts-for-unfinished-scenarios). -There is an option to save unfinished changes in the feature file as a draft. This is useful when the scenario isn't finalized yet and may contain syntax errors. +![Syntax error message example in the Gherkin test](./images/bdd-projects/2-gherkin-syntax-error.png) -Drafts can be applied at both the suite and test levels - in other words, Feature and Scenario description. -When editing a test, if the editor prevents you from saving changes (e.g., due to syntax errors), the relevant error message will appear at the bottom of the screen. If you plan to fix the scenario later but don’t want to lose your changes, you can use the **Save to Draft and View Test** option: - -![Save To Draft and View Test option](./images/Save_To_Draft_and_View_Test.png) +## Reuse Shared Steps -The next time you open the test in edit mode, you will see two additional buttons: +The same steps, such as `Given I am on the login page`, can be reused: -1. **Apply Draft to Description** – Applies the last saved draft to the scenario text section. +1. Start typing the step. +2. Pick it from the autocomplete list. -2. **Delete Draft** – Deletes the existing draft. +Reused steps have one big advantage: when a step changes, you edit it in one place and every scenario that uses it is updated. -![ Apply Draft to description and Delete Draft buttons](./images/apply_draft_or_delete_buttons.png) +See [Steps Database](https://docs.testomat.io/project/steps-snippets/steps/#how-to-reuse-steps-from-steps-database) for the full picture. -> **Note:** Only one draft can be saved at a time. +## Automation Mapping +In a BDD project, each Gherkin step is connected to a step definition in your automation code. For reusable tests, describe what the user wants to do rather than the exact UI action. -## Cross-Linking Tests, Suites and Folders +For example: -Another useful feature that allows you to cross-link test cases, suites, and folders by embedding their unique IDs directly into the description of another test or suite. This functionality provides you with clickable links to other related items within your project, and clicking on it displays a dynamic preview of the linked test, suite or folder in an additional window. -This feature is available for Classical and BDD projects but have a difference in formating. +```gherkin +When I cancel the transaction +``` -### For BDD Project +is easier to reuse than: -In the projects that use BDD format, you need to follow certain rules to maintain your test structure. -If you want to add clickable references to a test or suite in a BDD project, use **#** followed by their IDs. Clicking the link will open the test or suite in detail view, making navigation and traceability more seamless. +```gherkin +When I click the red Cancel button +``` -![Testomat.io - Use ID In Tests](./images/link_bdd.gif) +This also means your scenarios are less affected when the user interface changes. +To connect your scenarios to real code, import your feature files. See [Import Cucumber BDD Tests](https://docs.testomat.io/project/import-export/import/import-bdd). + +:::note + +As Gherkin alternative, you can use a Classical project and write CodeceptJS code that reads like BDD, such as `I.click('Login')`. See [Classical vs BDD](https://docs.testomat.io/project/tests/classical-vs-bdd#moving-between-project-types). + +::: + +## Suite Page + +Click a suite in the tree to open its page. This is where you see the feature file, its scenarios, and everything attached to it. + +| Tab | What it shows | +| --- | --- | +| **Feature description** | The `Feature` text of the file. | +| **Tests** | Every scenario in the file. | +| **Attachments** | Files added to the suite. | +| **Runs** | Runs that included these scenarios. | +| **History** | Changes made to the suite. | + +From this page you can also: + +| Control | What it does | +| --- | --- | +| **Edit** | Opens the feature file editor. | +| **Set milestone** | Links the suite to a [milestone](https://docs.testomat.io/advanced/milestones), such as a sprint or a release. | +| **Set labels** | Adds labels or custom fields. | +| **Set requirements** | Links the suite to a requirement document, so you can see what the scenarios are meant to cover. See [AI-Requirements](https://docs.testomat.io/advanced/ai-powered-features/ai-requirements). | +| **Suggest Tests** | Lets AI propose new scenarios based on the suite description. See [AI-Powered Features](https://docs.testomat.io/advanced/ai-powered-features/ai-powered-features). | +| **Add new test** | Adds a scenario without opening the editor. Type a title and click **Create**. Turn on **Bulk** to add several at once, one title per line. | + +## Feature File Editor + +A feature file is the suite in a BDD project. To open it: + +1. On the **Tests** page, click a suite in the tree. +2. Click **Edit** in the top-right corner. + +The editor opens with the `Feature` description and every scenario in the file. + +| # | Control | What it does | +|---|---|---| +| 1 | **Go back** | Return to the previous screen. | +| 2 | **Close** | Close the editor. | +| 3 | **Set milestone** | Link the feature file to a [milestone](https://docs.testomat.io/advanced/milestones), such as a sprint or a release. | +| 4 | **Set labels** | Add labels or custom fields. | +| 5 | **Gherkin** | Switch to the Gherkin view of the feature file. | +| 6 | **Autocomplete** | Turn step, snippet, and tag suggestions and the spell checker on or off. | +| 7 | **Fullscreen** | Open the editor in full-screen mode. | +| 8 | **Attachments** | Add files to the feature file. | +| 9 | **Editing area** | Edit the feature file and its Given/When/Then steps. | +| 10 | **Format** | Format the scenarios using the Gherkin structure. Shortcut: `Cmd` + `B`. | +| 11 | **Save** | Save your changes. Open the arrow next to it for more save options. | +| 12 | **Cancel** | Leave the editor without saving. | + +The **Autocomplete** menu holds four switches. + +| Switch | What it does | +| --- | --- | +| **Autocomplete Steps** | Suggests steps from the [Steps Database](https://docs.testomat.io/project/steps-snippets/steps) as you type. Pick one from the list to insert it. | +| **Autocomplete Snippets** | Suggests [snippets](https://docs.testomat.io/project/steps-snippets/snippets) - saved blocks of text or steps that you reuse across tests. | +| **Autocomplete Tags** | Suggests existing [tags](https://docs.testomat.io/advanced/tags-labels/tags) after you type `@`, so you reuse a tag instead of creating a duplicate. | +| **Spell check** | Marks misspelled words in the editor as you type. | + +The feature file editor and scenario editor work with the same file. Changes made to a scenario are saved back to its feature file. + +## Scenario Editor + +The scenario editor lets you edit the test without showing the rest of the feature file. You can open one scenario: + +1. Click a test in the tree. +2. Click **Edit**. + +![The BDD scenario editor in edit mode, with the controls numbered](./images/bdd-projects/3-testomatio-feature-file-editor.png) + +| # | Control | What it does | +|---|---|---| +| 1 | **Go back** | Return to the previous screen. | +| 2 | **State** | Change the test state, such as manual or automated. | +| 3 | **Help** | Open the help panel. | +| 4 | **Link to Issue** | Link the scenario to an issue in your bug tracker. | +| 5 | **Close** | Close the editor. | +| 6 | **Set milestone** | Link the scenario to a [milestone](https://docs.testomat.io/advanced/milestones), such as a sprint or a release. | +| 7 | **Set labels** | Add labels or custom fields. | +| 8 | **Gherkin** | Switch to the Gherkin view of the scenario. | +| 9 | **Priority** | Set how important the scenario is. | +| 10 | **Autocomplete** | Turn step, snippet, and tag suggestions and the spell checker on or off. | +| 11 | **Fullscreen** | Open the editor in full-screen mode. | +| 12 | **Attachments** | Add files to the scenario. | +| 13 | **Editing area** | Edit the scenario and its Given/When/Then steps. | +| 14 | **Save** | Save your changes. Open the arrow next to it for more save options. | +| 15 | **Cancel** | Leave the editor without saving. | + +## Drafts for Unfinished Scenarios + +Open the arrow next to **Save** to see every save option: + +| Option | What it does | +| --- | --- | +| **Save & View Test** | Saves and opens the test. | +| **Save & Go To Suite** | Saves and opens the feature file the scenario belongs to. | +| **Save To Draft & View Test** | Saves your changes as a draft and opens the test. | +| **Save & Close All** | Saves and closes the editor. | + +Use **Save To Draft & View Test** to keep unfinished changes. The draft is saved, while the test keeps its last valid version. + +When you open the test in edit mode again, you can use: + +- **Apply Draft to Description** to replace the current scenario text with the saved draft. +- **Delete Draft** to remove the saved draft. + +![The Save to Draft and View Test option in the save menu](./images/bdd-projects/4-feature-file-save-options.png) + +:::note + +Only one draft can be saved at a time. Saving a new draft replaces the previous one. + +::: + +## Link Tests and Suites + +You can link a test or suite from another description by adding `#` before its ID. The `#` is a must in a BDD project. + +For example: + +```text +#12345 +``` + +To link by ID: + +1. Save the description. The ID becomes a clickable link. +2. Click it to open the linked item in detail view. + +![A hash and a test ID into a scenario description, and the linked test opening in detail view](./images/bdd-projects/5-linked-test-in-bdd-test-description.png) + + + +## Next Steps + +- [Classical Test Case Editor](https://docs.testomat.io/project/tests/classical-test-case-editor) +- [Classical vs BDD](https://docs.testomat.io/project/tests/classical-vs-bdd) +- [AI-Agents](https://docs.testomat.io/advanced/ai-powered-features/ai-agents) diff --git a/src/content/docs/project/tests/classical-test-case-editor.md b/src/content/docs/project/tests/classical-test-case-editor.md index fbbc7872..283721b1 100644 --- a/src/content/docs/project/tests/classical-test-case-editor.md +++ b/src/content/docs/project/tests/classical-test-case-editor.md @@ -1,8 +1,8 @@ --- -title: Classical Test Case Editor +title: Classical Project description: Learn how to create effective test designs with Testomat.io. This guide covers building test scenarios, using various test design techniques, and integrating them into your project workflow for improved test case management and automated test runs. type: article -url: https://docs.testomat.io/project/classical_editor +url: https://docs.testomat.io/project/tests/classical-test-case-editor head: - tag: meta attrs: @@ -10,226 +10,146 @@ head: content: test design, test cases, test management, test automation, testing techniques, Testomat.io, BDD, Gherkin, Cucumber, test scenarios, project workflow, software testing --- -## Test Case Editor +A Classical project stores each test as a Markdown document. It is the default choice for manual testing. -Test Case Editor is a dynamic interface, designed to accommodate the diverse requirements of test case formulation. Through this platform, testers wield the power to architect meticulously structured test scenarios, encompassing a range of variables, actions, expected results, and potential outcomes. +Choose a Classical project if you: -Regarding test case creation, Testomat.io offers two distinct editor types: the **Classical** Editor and the **BDD** (Behavior-Driven Development) Editor. Each caters to different testing methodologies and user preferences, enabling testers to choose the approach that best aligns with their needs. +- are moving from spreadsheets or another test management system; +- work mostly with manual tests; +- use an automation framework that does not use Cucumber; +- want to write tests in your own words. -Let's have a look at **Classical** Editor. - -## Classical Editor Review - -Introducing the Classical Editor, a tool that places the art of test editing firmly in your hands. Crafting tests becomes a seamless endeavor as you immerse yourself in the Classical Editor's capabilities. - -![Classical Editor](./images/edit_test_classical_editor.png) - -# Test Editor Overview - -1. **Test Title Field** – Enter the title of your test and add relevant tags. -2. **Formatting Toolbar** – Use formatting options to enhance your text. -3. **Editing Area** – Add test requirements, preconditions, steps, and expected results. -4. **Preview Button** – View a live preview of how the test will appear. -5. **Edit Steps** – Open the steps editor to modify test steps and expected outcomes. -6. **Attachments Button** – Open the attachments dialog to upload supporting files. -7. **Draw Button** – Launch the drawing editor to add visual elements. -8. **Editor Mode Switch** – Toggle between block-based and Markdown editor modes. -9. **Autocomplete Steps** – Enable or disable automatic step suggestions. -10. **Autocomplete Snippets** – Enable or disable snippet suggestions. -11. **Autocomplete Tags** – Enable or disable tag suggestions. -12. **Full Screen Button** – Switch to a distraction-free, full-screen editing mode. -13. **Set Labels Button** – Open a window to assign existing labels or create custom fields. -14. **Use Template Button** – Apply a predefined test template. -15. **Change State** – Change the test state (e.g., from manual to automated). -16. **Save Button** – Save your progress. -17. **Go Back Button** – Return to the previous screen. -18. **Close Button** – Exit the test editor. +:::note +Choose the project type when you create the project. You cannot change it later. Classical projects do not support Gherkin scenarios. See [Classical vs BDD](https://docs.testomat.io/project/tests/classical-vs-bdd). -However, the Classical Editor's influence transcends singular tests. With Pre-Requirements, you can now wield the power to define the contextual prerequisites that set the stage for entire test **suites**. Seamlessly integrate high-level descriptions of dependencies, system states, or configurations required to execute a suite effectively. +::: -![Edit a suite](./images/edit_suite.png) +## Folders, Suites, and Tests -# Suite Editor Overview +A Classical project uses three types of items: folders, suites and tests. -1. **Suite Title Field** – Enter the suite title and any relevant tags. -2. **Formatting Toolbar** – Use text formatting tools as needed. -3. **Editing Area** – Provide a description for the suite. -4. **Preview Button** – See a live preview of the suite’s appearance. -5. **Attachments Button** – Open the dialog to upload attachments. -6. **Extra Menu Button** – Access additional suite editor options. -7. **Autocomplete Steps** – Enable or disable step autocompletion. -8. **Autocomplete Snippets** – Enable or disable snippet suggestions. -9. **Autocomplete Tags** – Enable or disable tag suggestions. -10. **Full Screen Button** – Enter distraction-free editing mode. -11. **Set Labels** – Assign existing labels or create new custom fields. -12. **Use Template Button** – Apply a predefined suite template. -13. **Save Button** – Save your changes. -14. **Go Back Button** – Return to the previous view. -15. **Close Button** – Exit the suite editor. +A folder can contain other folders and suites. A suite contains tests. Tests are the final level of the project structure. +Use folders to organize your suites. Use suites to group related tests. -### Why Do We Use Markdown in Classical Editor? +![Folder holds suites, a suite holds tests](./images/classical-projects/project-structure.png) -Markdown is a lightweight and versatile markup language that revolutionizes the way content is formatted and presented. It combines the simplicity of plain text with the ability to produce well-structured documents, making it a favored choice for various applications, including software documentation and test case creation. Here are its benefits: +You can also change an empty suite into a folder, or change a folder back into a suite. -**Simplified Syntax:** Markdown's straightforward syntax empowers testers to articulate intricate test scenarios with clarity. Utilize headings to structure test steps, employ bullet points for concise lists, and employ emphasis (bold, italic) to highlight crucial details. +This structure keeps your tests organized. You can also connect a manual test to automation later without moving it to another part of the project. -**Swift Formatting:** Testers can bid adieu to convoluted formatting menus and endless mouse clicks. Markdown's minimalist syntax allows testers to swiftly format text, enabling them to focus more on the content itself and less on the mechanics of formatting. This efficiency translates to accelerated test case creation. +## Suite Descriptions -**Collaboration Amplified:** Collaborative testing endeavors thrive on clear communication. Markdown's plain text format is version control-friendly, facilitating seamless collaboration using tools like Git. Team members can easily track changes, suggest modifications, and merge contributions, ensuring that test cases evolve cohesively. +A suite can have its own description. Use it for information that applies to all tests in the suite, such as: -**Readable and Accessible Content:** Markdown's clean and uncluttered appearance translates into test cases that are effortlessly readable, even by non-technical stakeholders. This enhances cross-functional communication by bridging the gap between testers, developers, and business analysts. +- system settings, +- dependencies, +- test data, +- setup steps. -**Media Integration:** Beyond text, Markdown accommodates image and file embedding. Testers can attach screenshots, diagrams, or supplementary documentation directly within test cases. This integration injects valuable context, aiding in comprehension and enabling more accurate bug reproduction. +Add this information once at the suite level instead of repeating it in every test. See [Suites and Folders](https://docs.testomat.io/project/tests/other-features-for-test-case-design/#suites-and-folders) for more information. -**Consistency and Templates:** Markdown's consistent structure allows for the creation of reusable test case templates. This ensures that test cases adhere to a standardized format, streamlining comprehension and navigation across a myriad of test scenarios. +## Test Descriptions -### Rich Editor for Classical Test Projects +Classical test descriptions use Markdown. With Markdown, you can add: -The editor follows a block-based layout, making it easier to structure and maintain detailed test cases. +- headings, +- lists, +- bold text, +- images, +- attachments. -It supports adding expected results for each step and attaching images directly within steps, improving clarity and documentation quality. The editor is fully compatible with the markdown format, enabling more effective use of AI features when creating and updating tests. \ +If you use the same structure for several tests, save it as a template and apply it with **Use template** in the editor. Templates are managed in project settings. See [Templates](https://docs.testomat.io/management/project/templates). :::note -The Classical editor page is already part of the tree. +AI-generated tests use the same Markdown format as manually created tests. ::: -The new editor improves test readability and structure, simplifies creation of detailed step-by-step scenarios, and enhances AI-assisted workflows through markdown compatibility. +![Test case editor with test description formatted as Markdown](./images/classical-projects/1-test-overview.png) -### Examples of Markdown Written Test Cases +## Tags -In the realm of Markdown-based test case creation, the handling of test unveils an array of versatile techniques. Below, we delve into several illustrative examples that showcase various methods for incorporating steps and expected results into your test cases. +Tags group tests across suites. Add a tag right in the test title with the `@` symbol: -In this pattern, the steps are listed one after the other, along with their respective expected results. This is a simple and straightforward way to document the steps for a test case. You can see expected results as plain text just after step. Need to mention that expected results in this way will no go to steps database and you won't have autocompletion for it. - -``` -## Steps - -* Step 1 - Expected result: Step 1 -* Step 2 - Expected result: Step 2 -* Step 3 - Expected result: Step 2 +```text +Checkout works with a saved card @smoke @payments ``` -Some example: +Testomat.io picks the tags out of the title and shows them next to the test. See [Tags](https://docs.testomat.io/advanced/tags-labels/tags). -``` -## Steps +## Test Priority -* Go to the payment page - Expected result: Payment page loads -* Enter credit card details and submit - Expected result: Payment is processed and confirmation page loads -``` +Priority shows which tests matter most. The priority icon appears next to the test title and in the test tree, and you can filter tests by it. ---- +| Level | Meaning | +| --- | --- | +| **Low** | Low-importance test | +| **Normal** | Default priority | +| **High** | High-importance test | -### Expected Results as Steps One After Another +Set priority when you create a test, change it while editing, or update many tests at once. See [Test Priority](https://docs.testomat.io/project/tests/test-case-creation-and-editing/#test-priority). -This pattern is similar to the previous one, but instead of listing the expected results right after each step as plain text, they are listed after all the steps have been documented. This approach will give you ability to use autocompletion and expected results will be stored in steps database. +## Steps and Expected Results -``` -## Steps -* Step 1 -* Expected result: Step 1 -* Step 2 -* Expected result: Step 2 -* Step 3 -* Expected result: Step 2 -``` +The Steps Database is a shared list of reusable steps for the whole project. It helps you: -Some example: +- find existing steps with autocomplete while writing a test, +- rename a step in one place and update it in every test that uses it. -``` -## Steps -* Go to the payment page -* Verify that Payment page loads -* Enter credit card details and submit -* Verify that Payment is processed and confirmation page loads -``` +Testomat.io saves a step to the Steps Database only when it is written as a list item under a `## Steps` heading. ---- +![A step written once goes into the Steps Database and is reused by every test](./images/classical-projects/steps-database.png) -### Steps with Expected Results as Nested List +:::note -This format is useful for breaking down each step into multiple sub-steps, each with its own expected result. This can be helpful when a step is complex and has several different parts or when there are multiple expected behaviors that need to be documented for each step. By nesting the expected results under each step, it's easy to see which expected results are related to which sub-steps, making it easier to track and verify expected behaviors. +If you want to reuse a step in other tests, create it as a list item from the start. -``` -## Steps -* Step 1 - 1. Expected result: Step 1.1 - 2. Expected result: Step 1.2 -* Step 2 - 1. Expected result: Step 2.1 - 2. Expected result: Step 2.2 -* Step 3 - 1. Expected result: Step 3.1 - 2. Expected result: Step 3.2 -``` +::: -Some example: +For example: -``` +```markdown ## Steps - * Go to the payment page - 1. Verify that Payment page loads +* Verify that Payment page loads * Enter credit card details and submit - 1. Verify that Credit card number is accepted - 2. Verify that Expiration date is accepted - 3. Verify that CVV code is accepted -* Submit payment and confirmation page loads - 1. Verify that Payment is processed +* Verify that Payment is processed and confirmation page loads ``` -:::note +| How you write it | What Testomat.io does | +| --- | --- | +| Plain text | Shows it in the test, but does not save it to the Steps Database | +| List item | Saves it and makes it available in autocomplete and the Steps editor | +| Nested list, table, or subheading | Saves it and makes it available in autocomplete and the Steps editor | -In case you use numbered list for your steps and unordered list for expected result or sub-steps, to see the correct formatting, **add 4 spaces or 1 tab** before unordered list. Check the relevant case below. +### Expected Results as Nested List -::: +This format is useful for breaking down each step into multiple sub-steps, each with its own expected result. -``` +```markdown ## Steps 1. Step 1 - - Expected result: Step 1.1 - - Expected result: Step 1.2 + - Expected result: Step 1.1 + - Expected result: Step 1.2 2. Step 2 - - Expected result: Step 2.1 - - Expected result: Step 2.2 + - Expected result: Step 2.1 + - Expected result: Step 2.2 3. Step 3 - - Expected result: Step 3.1 - - Expected result: Step 3.1 -``` - -Some example: - -``` -## Steps - -1. Go to the payment page - - Verify that Payment page loads - - Verify that payment page matches the design -2. Enter credit card details and submit - - Verify that Credit card number is accepted - - Verify that Expiration date is accepted - - Verify that CVV code is accepted -3. Submit payment and confirmation page loads - - Verify that Payment is processed + - Expected result: Step 3.1 + - Expected result: Step 3.2 ``` -![Edit Test Case](./images/Edit_test_case_numbered_list.gif) + Write expected results as list items if you want to save and reuse them. ---- +![Steps with their expected results in test case rich editor](./images/classical-projects/2-steps-with-expected-results.png) -### Steps with Separated Expected Results +### Separated Expected Results -Instead of listing the verification actions after each step, they are listed under a separate section for expected results. This can be a good way to provide a summary of the expected behavior and can be helpful in identifying any gaps in the test coverage. +The verification actions can be listed under a separate section for expected results. This can be used to provide a summary of the expected behavior and can be helpful in identifying any gaps in the test coverage. ``` ## Steps @@ -243,112 +163,113 @@ Instead of listing the verification actions after each step, they are listed und * Verify that ... ``` -Some example: - -``` -## Steps - -1. Go to the payment page -2. Enter credit card details and submit - -## Expected Results: - -1. Payment page loads -2. Payment is processed and confirmation page loads - -``` - ---- - -### Steps with Table of Expected Results - -In this pattern, the steps are presented in a table format, with the expected results listed in a separate column. This can be a good way to provide a clear and concise summary of the test case and can be helpful in identifying any variations in the expected behavior. - -``` -## Steps - -| Step | Expected results | -|---------------|------------------| -| Success login | Check form | -| Failed login | Check form | -``` - -Some example: - -``` -## Steps - -| Step | Expected results | -|--------------------------------|------------------------------------------------------------| -| Go to the payment page | Payment page loads | -| Enter credit card details | Credit card number is accepted, Expiration date is accepted, CVV code is accepted | -| Submit payment | Payment is processed and confirmation page loads | -``` - -## ![Testomat.io - Table inside test case description](./images/New_10TBA7jV_2024-08-03.png) - -### Steps with Expected Results as Subheadings - -In this format, the expected results are included as subheadings under each step. This can be useful when you want to provide a more detailed description of the expected behavior for each step. So each section will provide more complex details and many verification point per each step - -``` -## Steps - -### Step 1 - -* Expected result 1.1 -* Expected result 1.2 -* Expected result 1.3 - -### Step 2 - -* Expected result 2.1 -* Expected result 2.2 -* Expected result 2.3 - -### Step 3 - -* Expected result 2.1 -* Expected result 2.2 -* Expected result 2.3 -``` - -Some example: +When a test contains a `## Steps` heading, the preview shows steps in rich editor. Use it to edit steps and expected results without opening the full test editor. See [Steps](https://docs.testomat.io/project/steps-snippets/steps) for more information. -``` -## Steps - -### Go to the payment page - -* Verify that Payment page loads +## Dynamic Parameters -### Enter credit card details +Dynamic parameters turn one test into a data-driven test. Write a placeholder in the steps, fill in a table of values, and Testomat.io runs the test once per row. Each row counts as a separate test in the run. -* Enter credit card number - 1. Verify that Credit card number is accepted -* Enter expiration date - 1. Verify that Expiration date is accepted -* Enter CVV code - 1. Verify that CVV code is accepted - -### Submit payment - -* Verify that Payment is processed -* Verify that Confirmation page loads +Use `${ParameterName}` or `{{ParameterName}}` in the description or the steps: +```text +Open home page {{URL}} +Enter an invalid mobile number ${Mobile No} ``` -Use Markdown shortcuts to edit test case description quickly and easily. Visit the [Keyboard Shortcuts](https://docs.testomat.io/usage/keyboard-shortcuts/) page to learn more. - -## Cross-Linking Tests, Suites and Folders +See [Add Dynamic Parameters to a Test](https://docs.testomat.io/project/tests/test-case-creation-and-editing/#add-dynamic-parameters-to-a-test). + +## Automation Mapping +In a Classical project, Testomat.io connects automated tests to your test cases using the test title and file path. +Your manual test steps do not need to match functions in your automation code. You can describe the steps in plain language. This approach works with automation frameworks: + +- Playwright, +- Cypress, +- JUnit, +- pytest, +- RSpec. + +## Test Editor + +The Classical editor opens when you create a test or edit an existing one. + +![Test case editor overview](./images/classical-projects/3-testomatio-test-case-editor.png) + +It contains the test title, description, and tools for editing the test. + +| # | Control | What it does | +| --- | --- | --- | +| 1 | Test title field | Enter the test title and add tags. | +| 2 | Set priority | Set how important the test is, from Low to High. | +| 3 | Assign to | Assign the test to a user. The user must already be a member of the project. | +| 4 | Formatting toolbar | Format the test description. | +| 5 | Editing area | Add requirements, preconditions, steps, and expected results. | +| 6 | Preview | See how the finished test looks. | +| 7 | Edit steps | Edit steps and expected results in a Rich editor. | +| 8 | Attachments | Add files to the test. | +| 9 | Draw | Add a diagram or drawing. | +| 10 | Editor mode switch | Switch between block and Markdown modes. | +| 11 | Autocomplete steps | Turn step suggestions on or off. | +| 12 | Autocomplete snippets | Turn snippet suggestions on or off. | +| 13 | Autocomplete tags | Turn tag suggestions on or off. | +| 14 | Full screen | Open the editor in full-screen mode. | +| 15 | Set labels | Add labels or custom fields. | +| 16 | Use template | Apply a saved test template. | +| 17 | Change state | Change the test state, such as manual or automated. | +| 18 | Save | Save your changes. | +| 19 | Dictate | Speak the text instead of typing it. Needs AI features turned on. | +| 20 | Go back | Return to the previous screen. | +| 21 | Close | Close the editor. | + +## Suite Editor + +The suite editor works in much the same way, but it has fewer controls because suites do not have steps or a state. + +| # | Control | What it does | +| --- | --- | --- | +| 1 | Suite title field | Enter the suite title and add tags. | +| 2 | Formatting toolbar | Format the suite description. | +| 3 | Assign to | Assign the suite to a user. The user must already be a member of the project. | +| 4 | Editing area | Write the suite description. | +| 5 | Preview | See how the suite looks. | +| 6 | Attachments | Add files to the suite. | +| 7 | Extra menu | Open additional suite options. | +| 8 | Autocomplete steps | Turn step suggestions on or off. | +| 9 | Autocomplete snippets | Turn snippet suggestions on or off. | +| 10 | Autocomplete tags | Turn tag suggestions on or off. | +| 11 | Full screen | Open the editor in full-screen mode. | +| 12 | Set labels | Add labels or custom fields. | +| 13 | Use template | Apply a saved suite template. | +| 14 | Save | Save your changes. | +| 15 | Dictate | Speak the text instead of typing it. Needs AI features turned on. | +| 16 | Go back | Return to the previous screen. | +| 17 | Close | Close the editor. | + +## Block and Markdown Modes + +You can edit the same test description in two modes. + +The block editor splits the content into separate blocks. Each step can have its own expected result and image. This makes longer tests easier to read. +The Markdown editor shows the same content as Markdown view. + +Both modes edit the same description, so you can switch between them any time. + +## Link Tests and Suites + +You can link a test, suite, or folder from a description by adding its ID. + +After you save the description, the ID becomes a clickable link. Click it to open a preview of the linked item in a side panel. + +![Test case editor overview](./images/classical-projects/4-linked-test-in-test-description.png) + +If the ID stays as plain text, check that you added the item ID rather than its full URL. -Another useful feature that allows you to cross-link test cases, suites, and folders by embedding their unique IDs directly into the description of another test or suite. This functionality provides you with clickable links to other related items within your project, and clicking on it displays a dynamic preview of the linked test, suite or folder in an additional window. - -This feature is available for Classical and BDD projects but have a difference in formating. +:::note -### For Classical Project +In a Classical project, use the ID without `#`. -All you need to do is copy test cases/suites IDs and paste them into a test/suite description: +::: -![Testomat.io - Use ID In Tests](./images/New_0ldrsL29_2024-10-05.gif) +## Next Steps +- [BDD Test Case Editor](https://docs.testomat.io/project/tests/bdd-test-case-editor) +- [Classical vs BDD](https://docs.testomat.io/project/tests/classical-vs-bdd) diff --git a/src/content/docs/project/tests/classical-vs-bdd.md b/src/content/docs/project/tests/classical-vs-bdd.md index 363444e7..f22a64f3 100644 --- a/src/content/docs/project/tests/classical-vs-bdd.md +++ b/src/content/docs/project/tests/classical-vs-bdd.md @@ -10,160 +10,79 @@ head: content: test design, test cases, test management, test automation, testing techniques, Testomat.io, BDD, Gherkin, Cucumber, test scenarios, project workflow, software testing, Classical Project, BDD Project, Markdown, CodeceptJS, manual test, automation test, refactoring tests --- -In the world of quality assurance, choosing the right framework is like choosing the right foundation for a building. Maintaining clear boundaries between project types is essential for ensuring test suite integrity and automation stability. +Testomat.io has two project types: Classical and BDD. Both hold manual and automated tests. They differ in how you write a test, where its data lives, and how it connects to code. -While both, **Classical** and **BDD** projects, allow you to manage manual and automated tests, their underlying logic, syntax, and storage methods are fundamentally different. Below is a guide to help you understand these differences and why keeping them in separate projects is a technical necessity. +![Classical and BDD compared by format, main unit, and automation](./images/classical-vs-bdd.png) -## Classical vs BDD Projects +## Choose Your Project Type -In Testomat.io, projects are categorized into two distinct types: **Classical** and **BDD**. Choosing the right project type at the beginning of your testing journey is crucial, as the underlying architecture and syntax requirements differ significantly between the two. This choice determines your editor, your automation workflow, and how your team collaborates. +| Classical if you | BDD if you | +| --- | --- | +| Write mostly manual tests | Write scenarios with business, dev, and QA together | +| Move from spreadsheets or another TMS | Use a Cucumber-based framework | +| Want to describe steps in your own words | Want every step backed by code | -### Classical Projects +You choose the type when you create the project, and it cannot be changed later. -Classical projects are designed for maximum flexibility, primarily using **Markdown** formatting for test cases. This format is ideal for manual testing and traditional automation workflows where you describe how a test should be performed through detailed steps and expected results. +## Main Differences -- **Formatting:** Uses standard Markdown. -- **Structure:** Test-centric. Each test is an independent entity with its own description. -- **Automation:** Flexible mapping to various automation frameworks. -- **Best For:** Teams moving from spreadsheets or traditional TMS, and those using non-BDD automation frameworks (like Playwright, Cypress, or TestCafe). - -### BDD (Behavior-Driven Development) Projects - -BDD projects are built for collaboration and strict structure. They use **Gherkin syntax** (`Given`, `When`, `Then`). This project type is built with an automation-first mindset, ensuring that the business requirements and the test code stay in perfect synchronization. The goal here is to describe the behavior of the system in a way that business stakeholders, developers, and QAs all understand. - -- **Formatting:** Strictly follows Gherkin syntax rules. -- **Structure:** Feature-file centric. Tests (Scenarios) are organized within Feature Files. In Testomat.io, a suite in a BDD project represents a `.feature` file. -- **Automation:** Each step in the description must correspond to a specific function in the underlying test code. -- **Best For:** Teams practicing 'Three Amigos' (business, developers, QAs) collaboration and using Cucumber-based frameworks. Those who want their documentation to serve as the direct source of truth for automation. - -### Key Differences at a Glance - -| Feature | Classical Project | BDD Project | +| | Classical | BDD | | --- | --- | --- | -| **Editor** | Visual/Markdown Editor | Gherkin Editor (Scenario-based) | -| **Syntax** | Flexible (Bullet points, text) | Strict (Given, When, Then, And) | -| **Data Storage** | Inside the individual test case | Inside the Feature file (Suite level) | -| **Automation** | Syncs code to test descriptions | Syncs Feature files to step definitions | -| **Stakeholders** | Primarily QA and Developers | BA, Product Owners, Devs, and QA | -| **Main Focus** | Test execution steps | System behavior | - -## Why You Cannot Combine Both in One Project - -A common question is: **'Can I just add a few Gherkin tests to my Classical project?'** The short answer is **NO**. Testomat.io enforces a strict separation to protect your data integrity and workflow efficiency. Here is why: - -1. **Syntax Strictness vs. Flexibility** - -Gherkin is a much stricter format than Markdown. In a BDD project, the editor validates your syntax in real-time. If you try to move a flexible Markdown test into a Gherkin suite, the **syntax will break**. BDD requires specific keywords to function; without them, the 'Feature file' becomes unreadable to both the system and the automation parser. +| **Test format** | Markdown | Gherkin | +| **Editor** | Block and Markdown | Gherkin only | +| **Syntax** | Free-form | Fixed - `Given`, `When`, `Then`, `And` | +| **The main unit** | The test | The feature file | +| **Tags and details live** | On the test | In the feature file | +| **Automation matches by** | Test title and file path | Every step, one by one | +| **Templates** | Yes | No | +| **Invalid test** | Cannot happen | Saves as a draft until you fix it | -2. **Different Storage Architecture** +## Writing a Test -In a Classical project, metadata (tags, descriptions) is stored at the **individual test level**. In BDD, the 'truth' lives in the **Feature File**. A suite in BDD is not just a folder; it is a physical `.feature file`. Mixing these would create a 'logical mess' where the system wouldn't know whether to treat a file as a collection of independent tests or a single synchronized document. +Classical takes whatever you type. A step can be a sentence, a paragraph, or a table. -3. **Automation Mapping** +BDD reads Gherkin as you type. Misspell a keyword and the test will not save. -BDD automation relies on a 1:1 mapping between a Gherkin step and a function in your code. -**In BDD Projects:** Every step must have a corresponding function (Step Definition) in your code. -**In Classical Projects:** You have the freedom to write descriptive steps that don't necessarily map to code, providing more flexibility for manual testers. +![Gherkin editor showing a validation error on a scenario with a missing keyword](./images/bdd-projects/2-gherkin-syntax-error.png) -Attempting to support both in one project would lead to inconsistency. You would end up having some tests that require strict code-mapping and others that don't, leading to broken automation reports and confusing 'out-of-sync' notifications. +That is why BDD has **Save To Draft** and Classical does not. Free-form Markdown has nothing that can fail. -## Moving Between Project Types +## Moving a Test -Because of the strictness of Gherkin, there has traditionally been no "one-click" way to turn a flexible Markdown test into a rigid BDD scenario. However, with the integration of **AI-feature** within Testomat.io, you now have three distinct paths depending on your timeline and automation goals: +In Classical, a test carries its own data, so it moves or copies on its own. -**Option 1: AI-Powered Migration (Usign the 'Transform Project to BDD' AI-Agent)** +In BDD, you are moving a part of a document. Check that the feature file it came from still makes sense. -If you want to move your entire workspace to a BDD framework without the manual overhead, you can use the **'Transform Project to BDD'** feature. This AI-powered agent automatically analyzes your existing Classical tests and generates a new, structured BDD environment. +## Connecting to Code -- **How it works:** The AI rewrites your test steps into a valid `Given/When/Then` Gherkin syntax and generates a **completely new BDD project** containing the converted suite. +Classical matches a test to code by title. A step is free text, so it can describe an action no code performs. -- **Why use it:** It eliminates manual rewriting, standardizes test styles across the team, and makes your tests "automation-ready" in seconds. +BDD matches every line to a step definition. A line without one is a gap, not a description. -- **Key Benefit:** It bridges the gap between descriptive manual steps and strict BDD requirements automatically. +![Classical matches one test to code, BDD matches every step to its own definition](./images/automation-mapping.png) -:::note - -Read more about Testomat.io **'Transform Project to BDD'** and other AI-agents on a separate [AI-Agents](https://docs.testomat.io/advanced/ai-powered-features/ai-agents/) page. - -::: - -**Option 2: Manual Refactoring** +The payoff is reuse. Once `Given I am on the login page` has a definition, every scenario that needs a login reuses it. -For teams that want granular control or have highly complex logic that requires human nuance, manual refactoring remains the standard. +**Write one action per line.** A step that bundles three actions needs its own definition and fits nowhere else. -- **Classical → BDD:** You must create a new BDD project and manually rewrite tests to ensure each step follows Gherkin rules and is built for reusability. +## One Format per Project -- **BDD → Classical:** Currently, this direction is not supported as a direct migration due to the risk of losing the structured Feature file history and metadata. +You cannot add Gherkin tests to a Classical project. Some things can break: -**Option 3: The Hybrid Alternative (CodeceptJS)** - -If you aren't ready to commit to the strict overhead of Gherkin but want BDD-style readability, we recommend **CodeceptJS**. Instead of a full project migration, you stay in your Classical project and write code that looks like BDD. This allows you to write 'Human-Readable' code (e.g., `I.click('Login')`) that fits perfectly into Classical projects while remaining easy for non-technical stakeholders to follow. - -This gives you the descriptiveness of BDD without the strict overhead and formatting limitations of Gherkin. +| What breaks | Why | +| --- | --- | +| **Syntax** | A Markdown test in a Gherkin suite has no keywords. The feature file stops working in the editor and in your framework. | +| **Data** | One format keeps details on the test, the other in the file. The system cannot tell separate tests from one shared document. | +| **Automation** | Some tests would need a definition per line, others map to nothing on purpose. Half of the reports come out wrong. | :::note -Regardless of the method chosen, remember that BDD is a **'Behavioral Contract'**. Whether you use the AI or rewrite manually, ensure your team is prepared to map these new steps to corresponding functions in your automation code. +Moving a Classical project to BDD is a separate operation, not a setting. See [AI-Agents](https://docs.testomat.io/advanced/ai-powered-features/ai-agents). ::: -### Example of Refactoring from a Classical format to Gherkin - -Refactoring from a Classical format to Gherkin is less about changing the words and more about changing the philosophy. In a Classical project, you’re writing a 'How-to' guide for a human; in BDD, you’re writing a 'Behavioral Contract' that a machine can also read. - -Here is a common scenario—User Authentication—refactored to show the shift from flexibility to strictness. - -**Classical Project Manual Test:** - -**Format:** Markdown -In this format, you can be as descriptive or as brief as you like. You can combine multiple actions into one step. - -``` -Test Case: Successful Login - -1. Open the login page at https://app.testomat.io/login. -2. Enter a registered email and the correct password into the fields. -3. Hit the blue 'Sign In' button at the bottom of the form. - -Expected Result: The user is redirected to the Project Dashboard and sees a "Welcome" toast message. -``` - -**The Refactored Gherkin Scenario (BDD Project):** - -**Format:** Gherkin Syntax -Notice the use of specific keywords. Each line below would ideally map to a reusable 'Step Definition' in the automation code. - -``` -Feature: User Authentication -Scenario: Successful login with valid credentials - -Given the user is on the Testomat.io login page -When the user enters valid credentials -And the user clicks the 'Sign In' button -Then the user should be redirected to the Project Dashboard -And a "Welcome" message should be displayed -``` -**Why the BDD Version is 'Stricter'** -Switching to BDD isn't just a formatting change; it’s a shift toward a more disciplined testing architecture. Here is why the Gherkin format is considered 'stricter' than Classical Markdown: - -1. **Atomicity:** - -In a **Classical** project, a single step like `Login with valid credentials` is a black box — it’s easy to write but hard to automate efficiently. -**BDD** forces **Atomicity**. By breaking actions into individual lines (`Given I am on the login page`, `When I enter my email`), you create Reusable Building Blocks. If you have 50 tests that require a login, you only write the code for that 'step' once. In BDD, if a step isn't atomic, it isn't truly reusable. - -2. **Resilience to UI Fluctuation (Abstraction):** - -**Classical** tests often get bogged down in 'Implementation Noise' — mentioning a `red cancel button` or `the top-right dropdown`. If the UI changes, your documentation is instantly broken, 'outdated'. -**BDD** encourages **Abstract Logic**. You focus on the intent (e.g.,` When I cancel the transaction`) rather than the mechanics (`Click the red button`). This makes your test suite significantly more resilient to minor frontend updates. - -3. **State Management (Explicit Preconditions):** - -One of the biggest causes of flaky tests is a missing starting point. **Classical** tests often assume the user is already 'there'. -The `Given` keyword in **BDD** is a mandatory contract. It forces the author to define the exact state of the system before the action happens. This 'State Management' eliminates the "it works on my machine" excuse by ensuring every runner starts from the same functional baseline. - -4. **Syntax Enforcement (The Parser Factor):** - -In a **Classical** project, the editor is passive — it’s essentially a digital notepad. You can write whatever you want, and the system won't complain. -In **BDD**, the Gherkin Parser acts as a compiler. If you misspell a keyword or fail to follow the `Scenario:` structure, the test is syntactically invalid. This strictness ensures that your test suite is always machine-readable and ready for automation, preventing "junk" documentation from piling up. +## Next Steps -While the **Classical** project offers the 'freedom to write', the **BDD** project offers the 'structure to scale'. The strictness of BDD is an upfront investment that pays off in lower maintenance and more reliable automation. \ No newline at end of file +- [Classical Test Case Editor](https://docs.testomat.io/project/tests/classical-test-case-editor) +- [BDD Test Case Editor](https://docs.testomat.io/project/tests/bdd-test-case-editor) +- [AI-Agents](https://docs.testomat.io/advanced/ai-powered-features/ai-agents) \ No newline at end of file diff --git a/src/content/docs/project/tests/images/automation-mapping.png b/src/content/docs/project/tests/images/automation-mapping.png new file mode 100644 index 00000000..5f0361ea Binary files /dev/null and b/src/content/docs/project/tests/images/automation-mapping.png differ diff --git a/src/content/docs/project/tests/images/bdd-projects/1-test-overview.png b/src/content/docs/project/tests/images/bdd-projects/1-test-overview.png new file mode 100644 index 00000000..261a203f Binary files /dev/null and b/src/content/docs/project/tests/images/bdd-projects/1-test-overview.png differ diff --git a/src/content/docs/project/tests/images/bdd-projects/2-gherkin-syntax-error.png b/src/content/docs/project/tests/images/bdd-projects/2-gherkin-syntax-error.png new file mode 100644 index 00000000..38caae01 Binary files /dev/null and b/src/content/docs/project/tests/images/bdd-projects/2-gherkin-syntax-error.png differ diff --git a/src/content/docs/project/tests/images/bdd-projects/3-testomatio-feature-file-editor.png b/src/content/docs/project/tests/images/bdd-projects/3-testomatio-feature-file-editor.png new file mode 100644 index 00000000..ce564372 Binary files /dev/null and b/src/content/docs/project/tests/images/bdd-projects/3-testomatio-feature-file-editor.png differ diff --git a/src/content/docs/project/tests/images/bdd-projects/4-feature-file-save-options.png b/src/content/docs/project/tests/images/bdd-projects/4-feature-file-save-options.png new file mode 100644 index 00000000..decf6391 Binary files /dev/null and b/src/content/docs/project/tests/images/bdd-projects/4-feature-file-save-options.png differ diff --git a/src/content/docs/project/tests/images/bdd-projects/5-linked-test-in-bdd-test-description.png b/src/content/docs/project/tests/images/bdd-projects/5-linked-test-in-bdd-test-description.png new file mode 100644 index 00000000..7ee7716c Binary files /dev/null and b/src/content/docs/project/tests/images/bdd-projects/5-linked-test-in-bdd-test-description.png differ diff --git a/src/content/docs/project/tests/images/bdd-projects/bdd-project-structure.png b/src/content/docs/project/tests/images/bdd-projects/bdd-project-structure.png new file mode 100644 index 00000000..60d85eb7 Binary files /dev/null and b/src/content/docs/project/tests/images/bdd-projects/bdd-project-structure.png differ diff --git a/src/content/docs/project/tests/images/classical-projects/1-test-overview.png b/src/content/docs/project/tests/images/classical-projects/1-test-overview.png new file mode 100644 index 00000000..3a8b8bfe Binary files /dev/null and b/src/content/docs/project/tests/images/classical-projects/1-test-overview.png differ diff --git a/src/content/docs/project/tests/images/classical-projects/2-steps-with-expected-results.png b/src/content/docs/project/tests/images/classical-projects/2-steps-with-expected-results.png new file mode 100644 index 00000000..675fb672 Binary files /dev/null and b/src/content/docs/project/tests/images/classical-projects/2-steps-with-expected-results.png differ diff --git a/src/content/docs/project/tests/images/classical-projects/3-testomatio-test-case-editor.png b/src/content/docs/project/tests/images/classical-projects/3-testomatio-test-case-editor.png new file mode 100644 index 00000000..b7675bbd Binary files /dev/null and b/src/content/docs/project/tests/images/classical-projects/3-testomatio-test-case-editor.png differ diff --git a/src/content/docs/project/tests/images/classical-projects/4-linked-test-in-test-description.png b/src/content/docs/project/tests/images/classical-projects/4-linked-test-in-test-description.png new file mode 100644 index 00000000..3b1713b7 Binary files /dev/null and b/src/content/docs/project/tests/images/classical-projects/4-linked-test-in-test-description.png differ diff --git a/src/content/docs/project/tests/images/classical-projects/project-structure.png b/src/content/docs/project/tests/images/classical-projects/project-structure.png new file mode 100644 index 00000000..d00eed76 Binary files /dev/null and b/src/content/docs/project/tests/images/classical-projects/project-structure.png differ diff --git a/src/content/docs/project/tests/images/classical-projects/steps-database.png b/src/content/docs/project/tests/images/classical-projects/steps-database.png new file mode 100644 index 00000000..1557f9a5 Binary files /dev/null and b/src/content/docs/project/tests/images/classical-projects/steps-database.png differ diff --git a/src/content/docs/project/tests/images/classical-vs-bdd.png b/src/content/docs/project/tests/images/classical-vs-bdd.png new file mode 100644 index 00000000..14808054 Binary files /dev/null and b/src/content/docs/project/tests/images/classical-vs-bdd.png differ diff --git a/src/content/docs/project/tests/index.mdx b/src/content/docs/project/tests/index.mdx index 791d41ae..477be159 100644 --- a/src/content/docs/project/tests/index.mdx +++ b/src/content/docs/project/tests/index.mdx @@ -4,4 +4,9 @@ title: Overview import DirectoryLinks from '/src/components/DirectoryLinks.astro'; +The **Tests** page is where your test cases live. You can write them by hand, import them from your code, or do both in the same project. +This section explains how that works: how a project stores tests, how suites and folders fit together, how you write and edit a test, and what to do once the project gets too big to edit tests one at a time. +Start with the project type. Every project is either **Classical** or **BDD**. You choose it when you create the project, and you can't change it later. That one choice decides which editor you get, where your tags are kept, and how your tests connect to your code. +Not sure which type you have? Start with Classical vs BDD. + \ No newline at end of file