{"id":37765647,"url":"https://github.com/hrcorval/behavex","last_synced_at":"2026-05-18T01:10:51.327Z","repository":{"id":37796528,"uuid":"340412820","full_name":"hrcorval/behavex","owner":"hrcorval","description":"BDD testing solution designed to enhance your Behave-based testing workflows","archived":false,"fork":false,"pushed_at":"2026-05-16T17:14:05.000Z","size":2855,"stargazers_count":118,"open_issues_count":3,"forks_count":29,"subscribers_count":4,"default_branch":"master","last_synced_at":"2026-05-16T18:42:17.137Z","etag":null,"topics":["agile","agile-testing","automated-testing","automation","bdd","behave","behavex","gherkin","hacktoberfest","parallel","python","qa","test-automation","testing","testing-tools"],"latest_commit_sha":null,"homepage":"https://github.com/hrcorval/behavex","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/hrcorval.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGES.rst","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2021-02-19T15:36:40.000Z","updated_at":"2026-05-15T22:12:27.000Z","dependencies_parsed_at":"2024-04-17T21:27:10.525Z","dependency_job_id":"a214ed61-ddc7-4ec0-bb3e-cfafe2bf7852","html_url":"https://github.com/hrcorval/behavex","commit_stats":{"total_commits":75,"total_committers":6,"mean_commits":12.5,"dds":0.1466666666666666,"last_synced_commit":"04102b1318dfdd706505fefee6d83c016fc666a6"},"previous_names":[],"tags_count":15,"template":false,"template_full_name":null,"purl":"pkg:github/hrcorval/behavex","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hrcorval%2Fbehavex","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hrcorval%2Fbehavex/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hrcorval%2Fbehavex/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hrcorval%2Fbehavex/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/hrcorval","download_url":"https://codeload.github.com/hrcorval/behavex/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hrcorval%2Fbehavex/sbom","scorecard":{"id":57724,"data":{"date":"2025-08-04","repo":{"name":"github.com/hrcorval/behavex","commit":"4c3fe819baa13e5addf1d11ddb107e4c6ff764f2"},"scorecard":{"version":"v5.2.1-28-gc1d103a9","commit":"c1d103a9bb9f635ec7260bf9aa0699466fa4be0e"},"score":5.9,"checks":[{"name":"Packaging","score":-1,"reason":"packaging workflow not detected","details":["Warn: no GitHub/GitLab publishing workflow detected."],"documentation":{"short":"Determines if the project is published as a package that others can easily download, install, easily update, and uninstall.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#packaging"}},{"name":"Dangerous-Workflow","score":10,"reason":"no dangerous workflow patterns detected","details":null,"documentation":{"short":"Determines if the project's GitHub Action workflows avoid dangerous patterns.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#dangerous-workflow"}},{"name":"Token-Permissions","score":10,"reason":"GitHub workflow tokens follow principle of least privilege","details":["Info: topLevel 'contents' permission set to 'read': .github/workflows/python-package.yml:6","Info: no jobLevel write permissions found"],"documentation":{"short":"Determines if the project's workflows follow the principle of least privilege.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#token-permissions"}},{"name":"Maintained","score":10,"reason":"30 commit(s) and 14 issue activity found in the last 90 days -- score normalized to 10","details":null,"documentation":{"short":"Determines if the project is \"actively maintained\".","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#maintained"}},{"name":"Code-Review","score":0,"reason":"Found 0/3 approved changesets -- score normalized to 0","details":null,"documentation":{"short":"Determines if the project requires human code review before pull requests (aka merge requests) are merged.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#code-review"}},{"name":"CII-Best-Practices","score":0,"reason":"no effort to earn an OpenSSF best practices badge detected","details":null,"documentation":{"short":"Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#cii-best-practices"}},{"name":"Binary-Artifacts","score":10,"reason":"no binaries found in the repo","details":null,"documentation":{"short":"Determines if the project has generated executable (binary) artifacts in the source repository.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#binary-artifacts"}},{"name":"Pinned-Dependencies","score":0,"reason":"dependency not pinned by hash detected -- score normalized to 0","details":["Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/python-package.yml:23: update your workflow using https://app.stepsecurity.io/secureworkflow/hrcorval/behavex/python-package.yml/master?enable=pin","Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/python-package.yml:26: update your workflow using https://app.stepsecurity.io/secureworkflow/hrcorval/behavex/python-package.yml/master?enable=pin","Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/python-package.yml:56: update your workflow using https://app.stepsecurity.io/secureworkflow/hrcorval/behavex/python-package.yml/master?enable=pin","Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/python-package.yml:71: update your workflow using https://app.stepsecurity.io/secureworkflow/hrcorval/behavex/python-package.yml/master?enable=pin","Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/python-package.yml:74: update your workflow using https://app.stepsecurity.io/secureworkflow/hrcorval/behavex/python-package.yml/master?enable=pin","Warn: pipCommand not pinned by hash: .github/workflows/python-package.yml:32","Warn: pipCommand not pinned by hash: .github/workflows/python-package.yml:36","Warn: pipCommand not pinned by hash: .github/workflows/python-package.yml:37","Warn: pipCommand not pinned by hash: .github/workflows/python-package.yml:39","Warn: pipCommand not pinned by hash: .github/workflows/python-package.yml:40","Warn: pipCommand not pinned by hash: .github/workflows/python-package.yml:80","Warn: pipCommand not pinned by hash: .github/workflows/python-package.yml:81","Warn: pipCommand not pinned by hash: .github/workflows/python-package.yml:82","Warn: pipCommand not pinned by hash: .github/workflows/python-package.yml:83","Warn: pipCommand not pinned by hash: .github/workflows/python-package.yml:84","Warn: pipCommand not pinned by hash: .github/workflows/python-package.yml:86","Info:   0 out of   5 GitHub-owned GitHubAction dependencies pinned","Info:   0 out of  11 pipCommand dependencies pinned"],"documentation":{"short":"Determines if the project has declared and pinned the dependencies of its build process.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#pinned-dependencies"}},{"name":"Security-Policy","score":0,"reason":"security policy file not detected","details":["Warn: no security policy file detected","Warn: no security file to analyze","Warn: no security file to analyze","Warn: no security file to analyze"],"documentation":{"short":"Determines if the project has published a security policy.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#security-policy"}},{"name":"Fuzzing","score":0,"reason":"project is not fuzzed","details":["Warn: no fuzzer integrations found"],"documentation":{"short":"Determines if the project uses fuzzing.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#fuzzing"}},{"name":"License","score":10,"reason":"license file detected","details":["Info: project has a license file: LICENSE:0","Info: FSF or OSI recognized license: MIT License: LICENSE:0"],"documentation":{"short":"Determines if the project has defined a license.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#license"}},{"name":"Vulnerabilities","score":10,"reason":"0 existing vulnerabilities detected","details":null,"documentation":{"short":"Determines if the project has open, known unfixed vulnerabilities.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#vulnerabilities"}},{"name":"Signed-Releases","score":-1,"reason":"no releases found","details":null,"documentation":{"short":"Determines if the project cryptographically signs release artifacts.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#signed-releases"}},{"name":"Branch-Protection","score":0,"reason":"branch protection not enabled on development/release branches","details":["Warn: branch protection not enabled for branch 'master'"],"documentation":{"short":"Determines if the default and release branches are protected with GitHub's branch protection settings.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#branch-protection"}},{"name":"SAST","score":10,"reason":"SAST tool is run on all commits","details":["Info: all commits (30) are checked with a SAST tool"],"documentation":{"short":"Determines if the project uses static code analysis.","url":"https://github.com/ossf/scorecard/blob/c1d103a9bb9f635ec7260bf9aa0699466fa4be0e/docs/checks.md#sast"}}]},"last_synced_at":"2025-08-15T01:06:35.438Z","repository_id":37796528,"created_at":"2025-08-15T01:06:35.438Z","updated_at":"2025-08-15T01:06:35.438Z"},"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33161421,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-17T22:39:12.733Z","status":"ssl_error","status_checked_at":"2026-05-17T22:39:10.741Z","response_time":107,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["agile","agile-testing","automated-testing","automation","bdd","behave","behavex","gherkin","hacktoberfest","parallel","python","qa","test-automation","testing","testing-tools"],"created_at":"2026-01-16T14:42:16.332Z","updated_at":"2026-05-18T01:10:51.304Z","avatar_url":"https://github.com/hrcorval.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"[![Downloads](https://static.pepy.tech/badge/behavex)](https://pepy.tech/project/behavex)\n[![PyPI version](https://badge.fury.io/py/behavex.svg)](https://badge.fury.io/py/behavex)\n[![Python Versions](https://img.shields.io/pypi/pyversions/behavex.svg)](https://pypi.org/project/behavex/)\n[![Dependency Status](https://img.shields.io/librariesio/github/hrcorval/behavex)](https://libraries.io/github/hrcorval/behavex)\n[![License](https://img.shields.io/github/license/hrcorval/behavex.svg)](https://github.com/hrcorval/behavex/blob/main/LICENSE)\n[![Build Status](https://github.com/hrcorval/behavex/actions/workflows/python-package.yml/badge.svg)](https://github.com/hrcorval/behavex/actions)\n[![GitHub last commit](https://img.shields.io/github/last-commit/hrcorval/behavex.svg)](https://github.com/hrcorval/behavex/commits/main)\n\n# BehaveX Documentation\n\n## ✨ Latest Features\n\nJust to mention the most important features delivered in latest BehaveX releases:\n\n🏷️ **Tag Expressions v2 Support** *(v4.6.0)* - Native support for Cucumber-style tag expressions with boolean logic (and, or, not), parentheses grouping, wildcard matching (@prefix*, @*suffix, @*substring*), and complex filtering. Supported in Behave 1.3.0+ using zero external dependencies. See [Tag Expressions](#tag-expressions) for comprehensive examples and usage.\n\n🚀 **Enhanced Behave Integration** *(v4.5.0)* - Added support for newer behave versions (\u003e= 1.3.0). Also, major performance overhaul using direct Behave Runner class integration, providing better programmatic control with improved status detection efficiency. See [Migration to BehaveX 4.5.0](#migration-to-behavex-450--behave--130) for upgrade considerations.\n\n🛠️ **Enhanced Error Status Handling** *(v4.5.0)* - Comprehensive improvements in \"error\" status management, now preserving original \"error\" status instead of converting to \"failed\" for more accurate reporting.\n\n📊 **Interactive Execution Timeline Chart** *(v4.5.0)* - New visual timeline in HTML reports displaying scenario execution order, duration, and status across parallel processes.\n\n🎯 **Test Execution Ordering** *(v4.4.1)* - Control the sequence of scenario and feature execution during parallel runs using order tags (e.g., `@ORDER_001`, `@ORDER_010`). Now includes strict ordering mode (`--order-tests-strict`) for scenarios that must wait for lower-order tests to complete.\n\n📊 **Allure Reports Integration** *(v4.2.1)* - Generate beautiful, comprehensive test reports with Allure framework integration.\n\n📈 **Console Progress Bar** *(v3.2.13)* - Real-time progress tracking during parallel test execution.\n\n## Table of Contents\n- [Introduction](#introduction)\n- [Features](#features)\n- [Installation Instructions](#installation-instructions)\n- [Migration to BehaveX 4.5.0](#migration-to-behavex-450--behave--130)\n- [Execution Instructions](#execution-instructions)\n- [Tag Expressions](#tag-expressions)\n- [Constraints](#constraints)\n- [Supported Behave Arguments](#supported-behave-arguments)\n- [Specific Arguments from BehaveX](#specific-arguments-from-behavex)\n- [Parallel Test Executions](#parallel-test-executions)\n- [Test Execution Ordering](#test-execution-ordering)\n- [Test Execution Reports](#test-execution-reports)\n- [Attaching Images to the HTML Report](#attaching-images-to-the-html-report)\n- [Attaching Additional Execution Evidence to the HTML Report](#attaching-additional-execution-evidence-to-the-html-report)\n- [Test Logs per Scenario](#test-logs-per-scenario)\n- [Metrics and Insights](#metrics-and-insights)\n- [Dry Runs](#dry-runs)\n- [Muting Test Scenarios](#muting-test-scenarios)\n- [Handling Failing Scenarios](#handling-failing-scenarios)\n- [Displaying Progress Bar in Console](#displaying-progress-bar-in-console)\n- [Allure Reports Integration](#allure-reports-integration)\n- [Show Your Support](#show-your-support)\n\n## Introduction\n\n**BehaveX** is a BDD testing solution built on top of the Python Behave library, orchestrating parallel test sessions to enhance your testing workflow with additional features and performance improvements. It's particularly beneficial in the following scenarios:\n\n- **Accelerating test execution**: Significantly reduce test run times through parallel execution by feature or scenario.\n- **Enhancing test reporting**: Generate comprehensive and visually appealing HTML and JSON reports for in-depth analysis and integration with other tools.\n- **Improving test visibility**: Provide detailed evidence, such as screenshots and logs, essential for understanding test failures and successes.\n- **Optimizing test automation**: Utilize features like test retries, test muting, and performance metrics for efficient test maintenance and analysis.\n- **Managing complex test suites**: Handle large test suites with advanced features for organization, execution, and comprehensive reporting through multiple formats and custom formatters.\n\n## Features\n\nBehaveX provides the following features:\n\n- **Parallel Test Executions**: Execute tests using multiple processes, either by feature or by scenario.\n- **Enhanced Reporting**: Generate comprehensive reports in multiple formats (HTML, JSON, JUnit) and utilize custom formatters like Allure for advanced reporting capabilities that can be exported and integrated with third-party tools.\n- **Evidence Collection**: Include images/screenshots and additional evidence in the HTML report.\n- **Test Logs**: Automatically compile logs generated during test execution into individual log reports for each scenario.\n- **Test Muting**: Add the `@MUTE` tag to test scenarios to execute them without including them in JUnit reports.\n- **Execution Metrics**: Generate metrics in the HTML report for the executed test suite, including Automation Rate, Pass Rate, Steps execution counter and average execution time.\n- **Dry Runs**: Perform dry runs to see the full list of scenarios in the HTML report without executing the tests. It overrides the `-d` Behave argument.\n- **Auto-Retry for Failing Scenarios**: Use the `@AUTORETRY` tag to automatically re-execute failing scenarios. Also, you can re-run all failing scenarios using the **failing_scenarios.txt** file.\n\n![Test Execution Report](https://github.com/hrcorval/behavex/blob/master/img/html_test_report.png?raw=true)\n![Test Execution Report](https://github.com/hrcorval/behavex/blob/master/img/html_test_report_2.png?raw=true)\n![Test Execution Report](https://github.com/hrcorval/behavex/blob/master/img/html_test_report_3.png?raw=true)\n\n## Installation Instructions\n\nTo install BehaveX, execute the following command:\n\n```bash\npip install behavex\n```\n\n### Behave Version Compatibility\n\nBehaveX is compatible with the following Behave versions:\n\n- **Behave 1.2.6** (stable, widely tested)\n- **Behave \u003e= 1.3.0**\n\nBehaveX automatically installs a compatible version of Behave. If you need to use a specific version of Behave, you can install it explicitly:\n\n```bash\n# For Behave 1.2.6 (stable)\npip install behavex behave==1.2.6\n\n# For Behave 1.3.0 or newer (latest)\npip install behavex behave\u003e=1.3.0\n```\n\n**Note**: BehaveX includes compatibility fixes to ensure all features work correctly with multiple Behave versions.\n\n## Migration to BehaveX 4.5.0 + Behave \u003e= 1.3.0\n\nWhen upgrading to BehaveX 4.5.0 with Behave 1.3.0 or newer, be aware of the following potential challenges:\n\n### Breaking Changes in Behave \u003e= 1.3.0 that we experienced when moving from behave 1.2.6\n\n- **Case-sensitive step definitions**: Step definitions are case-sensitive. If the case doesn't match exactly between your feature files and step definitions, you'll encounter \"undefined step\" errors.\n\n- **Trailing colons in steps**: Steps with trailing colons (`:`) are no longer automatically cleaned by Behave and may not be detected properly.\n\n- **Relative imports**: Using relative paths in imports may cause issues. Consider updating to absolute import paths for better compatibility.\n\n### BehaveX 4.5.0 Changes\n\n- **Error status preservation**: BehaveX now preserves the original \"error\" status from Behave instead of converting it to \"failed\" (except in HTML reports for visualization). This provides more accurate status reporting but may affect tools expecting the previous behavior.\n\n### Resources\n\nFor complete details on Behave breaking changes, refer to:\n- [Behave Documentation](https://behave.readthedocs.io/en/latest/new_and_noteworthy/)\n\n## Execution Instructions\n\nExecute BehaveX in the same way as Behave from the command line, using the `behavex` command. Here are some examples:\n\n- **Run scenarios tagged as `TAG_1` but not `TAG_2`:**\n  ```bash\n  # v1 syntax (all Behave versions)\n  behavex -t=@TAG_1 -t=~@TAG_2\n\n  # v2 syntax (Cucumber Style, supported in Behave 1.3.0+)\n  behavex -t=\"@TAG_1 and not @TAG_2\"\n  ```\n\n- **Run scenarios tagged as `TAG_1` or `TAG_2`:**\n  ```bash\n  # v1 syntax (all Behave versions)\n  behavex -t=@TAG_1,@TAG_2\n\n  # v2 syntax (Cucumber Style, supported in Behave 1.3.0+)\n  behavex -t=\"@TAG_1 or @TAG_2\"\n  ```\n\n- **Run scenarios tagged as `TAG_1` using 4 parallel processes:**\n  ```bash\n  behavex -t=@TAG_1 --parallel-processes=4 --parallel-scheme=scenario\n  ```\n\n- **Run scenarios located at specific folders using 2 parallel processes:**\n  ```bash\n  behavex features/features_folder_1 features/features_folder_2 --parallel-processes=2\n  ```\n\n- **Run scenarios from a specific feature file using 2 parallel processes:**\n  ```bash\n  behavex features_folder_1/sample_feature.feature --parallel-processes=2\n  ```\n\n- **Run scenarios tagged as `TAG_1` from a specific feature file using 2 parallel processes:**\n  ```bash\n  behavex features_folder_1/sample_feature.feature -t=@TAG_1 --parallel-processes=2\n  ```\n\n- **Run scenarios located at specific folders using 2 parallel processes:**\n  ```bash\n  behavex features/feature_1 features/feature_2 --parallel-processes=2\n  ```\n\n- **Run scenarios tagged as `TAG_1`, using 5 parallel processes executing a feature on each process:**\n  ```bash\n  behavex -t=@TAG_1 --parallel-processes=5 --parallel-scheme=feature\n  ```\n\n- **Perform a dry run of the scenarios tagged as `TAG_1`, and generate the HTML report:**\n  ```bash\n  behavex -t=@TAG_1 --dry-run\n  ```\n\n- **Run scenarios tagged as `TAG_1`, generating the execution evidence into a specific folder:**\n  ```bash\n  behavex -t=@TAG_1 -o=execution_evidence\n  ```\n\n- **Run scenarios with execution ordering enabled (requires parallel execution):**\n  ```bash\n  behavex -t=@TAG_1 --order-tests --parallel-processes=2\n  ```\n\n- **Run scenarios with strict execution ordering (tests wait for lower order tests to complete):**\n  ```bash\n  behavex -t=@TAG_1 --order-tests-strict --parallel-processes=2\n  ```\n\n- **Run complex tag expressions (Cucumber Style, supported in Behave 1.3.0+):**\n  ```bash\n  # Advanced filtering with wildcards\n  behavex -t=\"@smoke* and not @*_slow\" --parallel-processes=3\n\n  # Production-ready filtering\n  behavex -t=\"(@api or @ui) and @high_priority and not @flaky\" --parallel-processes=4\n  ```\n\n- **Run scenarios with custom order tag prefix and parallel execution:**\n  ```bash\n  behavex --order-tests --order-tag-prefix=PRIORITY --parallel-processes=3\n  ```\n\n## Tag Expressions\n\nBehaveX supports two types of tag expressions for filtering test scenarios:\n\n### Tag Expressions v1 (Legacy Format)\n\nTag Expressions v1 use a simple syntax compatible with all Behave versions:\n\n**Basic Examples:**\n```bash\n# Run scenarios with a specific tag\nbehavex -t=@smoke\n\n# Exclude scenarios with a tag\nbehavex -t=~@slow\n\n# Multiple conditions (AND logic)\nbehavex -t=@smoke -t=~@slow\n\n# Multiple tags (OR logic)\nbehavex -t=@smoke,@regression\n```\n\n**Advanced v1 Examples:**\n```bash\n# Run smoke tests but exclude slow ones\nbehavex -t=@smoke -t=~@slow\n\n# Run regression or integration tests\nbehavex -t=@regression,@integration\n\n# Run critical tests but exclude known issues\nbehavex -t=@critical -t=~@known_issue\n\n# Complex filtering with multiple exclusions\nbehavex -t=@api -t=~@slow -t=~@flaky\n```\n\n### Tag Expressions v2 (Cucumber Style, supported in Behave 1.3.0+)\n\n\u003e **Note:** Tag Expressions v2 (Cucumber Style) require **Behave 1.3.0 or newer**. BehaveX will automatically detect v2 syntax and use Behave's native parser.\n\nTag Expressions v2 support advanced boolean logic with a more intuitive syntax:\n\n**Boolean Operators:**\n```bash\n# AND logic\nbehavex -t=\"@smoke and @api\"\n\n# OR logic\nbehavex -t=\"@smoke or @regression\"\n\n# NOT logic\nbehavex -t=\"not @slow\"\n\n# Complex combinations\nbehavex -t=\"@smoke and not @slow\"\n```\n\n**Parentheses Grouping:**\n```bash\n# Group conditions with parentheses\nbehavex -t=\"(@smoke or @regression) and not @slow\"\n\n# Complex nested grouping\nbehavex -t=\"(@smoke and @api) or (@regression and @ui)\"\n\n# Deep nesting\nbehavex -t=\"(((@smoke or @regression) and @api) or @critical) and not @slow\"\n```\n\n**Wildcard Matching (Cucumber Style Feature, supported in Behave 1.3.0+):**\n```bash\n# Prefix matching\nbehavex -t=\"@smoke*\"                    # Matches @smoke, @smoke_test, @smoke_api\n\n# Suffix matching\nbehavex -t=\"@*_test\"                    # Matches @api_test, @ui_test, @smoke_test\n\n# Substring matching\nbehavex -t=\"@*smoke*\"                   # Matches @smoke, @smoke_test, @test_smoke\n\n# Complex wildcard combinations\nbehavex -t=\"@smoke* and not @*_slow\"    # Smoke tests excluding slow ones\nbehavex -t=\"@*_api or @*_ui\"            # All API or UI tests\n```\n\n**Advanced v2 Examples:**\n```bash\n# Production-ready test filtering\nbehavex -t=\"(@smoke or @regression) and not (@slow or @flaky)\"\n\n# Environment-specific testing\nbehavex -t=\"@api and (@staging or @production) and not @experimental\"\n\n# Feature-based filtering with wildcards\nbehavex -t=\"@user* and (@*_positive or @*_critical) and not @*_slow\"\n\n# Complex business logic filtering\nbehavex -t=\"((@smoke and @high_priority) or @critical) and not (@known_issue or @skip)\"\n\n# Multi-level wildcard filtering\nbehavex -t=\"(@auth* or @payment*) and (@*_test or @*_check) and not @*_manual\"\n```\n\n**Multiple Tag Arguments (Combined with AND logic):**\n```bash\n# Multiple -t arguments are combined with AND\nbehavex -t=\"@smoke or @regression\" -t=\"not @slow\"\n# Equivalent to: (@smoke or @regression) and (not @slow)\n\n# Complex multi-argument filtering\nbehavex -t=\"@api* and @*_test\" -t=\"not @experimental\" -t=\"@high_priority or @critical\"\n```\n\n### Version Compatibility\n\n| Feature | Behave 1.2.6 | Behave 1.3.0+ |\n|---------|---------------|----------------|\n| Tag Expressions v1 | ✅ Full Support | ✅ Full Support |\n| Tag Expressions v2 | ❌ Not Supported | ✅ Full Support |\n| Boolean operators (and, or, not) | ❌ | ✅ |\n| Parentheses grouping | ❌ | ✅ |\n| Wildcard matching | ❌ | ✅ |\n\n### Migration from v1 to v2\n\nWhen upgrading to Behave 1.3.0+, you can migrate your tag expressions:\n\n```bash\n# v1 Format                          # v2 Equivalent\nbehavex -t=@smoke -t=~@slow         →  behavex -t=\"@smoke and not @slow\"\nbehavex -t=@smoke,@regression       →  behavex -t=\"@smoke or @regression\"\nbehavex -t=@api -t=~@slow -t=~@flaky → behavex -t=\"@api and not @slow and not @flaky\"\n```\n\n### Best Practices\n\n- **Use quotes** around v2 expressions to prevent shell interpretation\n- **Test expressions** with `--dry-run` to verify scenario selection\n- **Prefer v2 syntax** for better readability when using Behave 1.3.0+\n- **Use wildcards** to reduce maintenance when tag naming follows patterns\n- **Group complex logic** with parentheses for clarity\n\n## Constraints\n\n- Not all Behave arguments are yet supported.\n- Parallel execution is implemented using concurrent Behave processes. This means that any hooks defined in the `environment.py` module will run in each parallel process. This includes the **before_all** and **after_all** hooks, which will execute in every parallel process. The same is true for the **before_feature** and **after_feature** hooks when parallel execution is organized by scenario.\n\n## Supported Behave Arguments\n\n- no_color\n- color\n- define\n- exclude\n- include\n- no_snippets\n- no_capture\n- name\n- capture\n- no_capture_stderr\n- capture_stderr\n- no_logcapture\n- logcapture\n- logging_level\n- summary\n- quiet\n- stop\n- tags\n- tags-help\n\n**Important**: Some arguments do not apply when executing tests with more than one parallel process, such as **stop** and **color**.\n\n## Specific Arguments from BehaveX\n\n- **output-folder** (-o or --output-folder): Specifies the output folder for execution reports (JUnit, HTML, JSON).\n- **dry-run** (-d or --dry-run): Performs a dry-run by listing scenarios in the output reports.\n- **parallel-processes** (--parallel-processes): Specifies the number of parallel Behave processes.\n- **parallel-scheme** (--parallel-scheme): Performs parallel test execution by [scenario|feature].\n- **show-progress-bar** (--show-progress-bar): Displays a progress bar in the console during parallel test execution.\n- **formatter** (--formatter): Specifies a custom formatter for test reports (e.g., Allure formatter).\n- **formatter-outdir** (--formatter-outdir): Specifies the output directory for formatter results (default: output/allure-results for Allure).\n- **no-formatter-attach-logs** (--no-formatter-attach-logs): Disables automatic attachment of scenario log files to formatter reports.\n- **order-tests** (--order-tests): Enables sorting of scenarios/features by execution order using special order tags (only effective with parallel execution).\n- **order-tests-strict** (--order-tests-strict): Ensures tests run in strict order in parallel mode, with tests waiting for lower-order tests to complete (automatically enables --order-tests). May reduce parallel execution performance.\n- **order-tag-prefix** (--order-tag-prefix): Specifies the prefix for order tags (default: 'ORDER').\n\n## Parallel Test Executions\n\nBehaveX manages concurrent executions of Behave instances in multiple processes. You can perform parallel test executions by feature or scenario. When the parallel scheme is by scenario, the examples of a scenario outline are also executed in parallel.\n\n![Parallel Test Executions](https://github.com/hrcorval/behavex/blob/master/img/behavex_parallel_executions.png?raw=true)\n\n### Examples:\n```bash\nbehavex --parallel-processes=3\nbehavex -t=@TAG --parallel-processes=3\nbehavex -t=@TAG --parallel-processes=2 --parallel-scheme=scenario\nbehavex -t=@TAG --parallel-processes=5 --parallel-scheme=feature\nbehavex -t=@TAG --parallel-processes=5 --parallel-scheme=feature --show-progress-bar\n```\n\nFor advanced tag filtering examples, see the [Tag Expressions](#tag-expressions) section.\n\n### Identifying Each Parallel Process\n\nBehaveX populates the Behave contexts with the `worker_id` user-specific data. This variable contains the id of the current behave process.\n\nFor example, if BehaveX is started with `--parallel-processes 2`, the first instance of behave will receive `worker_id=0`, and the second instance will receive `worker_id=1`.\n\nThis variable can be accessed within the python tests using `context.config.userdata['worker_id']`.\n\n## Test Execution Ordering\n\nBehaveX provides the ability to control the execution order of your test scenarios and features using special order tags when running tests in parallel. This feature ensures that tests run in a predictable sequence during parallel execution, which is particularly useful for setup/teardown scenarios, or when you need specific tests to run before others.\n\n### Purpose and Use Cases\n\nTest execution ordering is valuable in scenarios such as:\n\n- **Setup and Teardown**: Ensure setup scenarios run first and cleanup scenarios run last\n- **Data Dependencies**: Execute data creation tests before tests that consume that data\n- **Performance Testing**: Control the sequence to avoid resource conflicts\n- **Smoke Testing**: Prioritize critical smoke tests to run first\n- **Parallel Execution Optimization**: Run slower test scenarios first to maximize parallel process utilization and minimize overall execution time\n\n### Command Line Arguments\n\nBehaveX provides three arguments to control test execution ordering during parallel execution:\n\n- **--order-tests** or **--order_tests**: Enables sorting of scenarios/features by execution order using special order tags (only effective with parallel execution)\n- **--order-tests-strict** or **--order_tests_strict**: Ensures tests run in strict order in parallel mode (automatically enables --order-tests). Tests with higher order numbers will wait for all tests with lower order numbers to complete first. Note: This may reduce parallel execution performance as processes must wait for lower-order tests to complete.\n- **--order-tag-prefix** or **--order_tag_prefix**: Specifies the prefix for order tags (default: 'ORDER')\n\n### How to Use Order Tags\n\nTo control execution order, add tags to your scenarios using the following format:\n\n```gherkin\n@ORDER_001\nScenario: This scenario will run first\n    Given I perform initial setup\n    When I execute the first test\n    Then the setup should be complete\n\n@ORDER_010\nScenario: This scenario will run second\n    Given the initial setup is complete\n    When I execute the dependent test\n    Then the test should pass\n\n@ORDER_100\nScenario: This scenario will run last\n    Given all previous tests have completed\n    When I perform cleanup\n    Then all resources should be cleaned up\n```\n\n**Important Notes:**\n- Test execution ordering only works when running tests in parallel (`--parallel-processes \u003e 1`)\n- Lower numbers execute first (e.g., `@ORDER_001` runs before `@ORDER_010`)\n- Scenarios without order tags will run after all ordered scenarios (Default order: 9999)\n- To run scenarios at the end of execution, you can use order numbers greater than 9999 (e.g., `@ORDER_10000`)\n- **Regular ordering** (`--order-tests`): When the number of parallel processes equals or exceeds the number of ordered scenarios, ordering has no practical effect since all scenarios can run simultaneously\n- **Strict ordering** (`--order-tests-strict`): Tests will always wait for lower-order tests to complete, regardless of available processes, which may reduce overall execution performance\n- Use zero-padded numbers (e.g., `001`, `010`, `100`) for better sorting visualization\n- The order tags work with both parallel feature and scenario execution schemes\n- `--order-tests-strict` automatically enables `--order-tests`, so you don't need to specify both arguments\n\n### Execution Examples\n\n#### Basic Ordering\n```bash\n# Enable test ordering with default ORDER prefix (requires parallel execution)\nbehavex --order-tests --parallel-processes=2 -t=@SMOKE\n\n# Enable test ordering with custom prefix\nbehavex --order-tests --order-tag-prefix=PRIORITY --parallel-processes=3 -t=@REGRESSION\n```\n\n#### Strict Ordering (Wait for Lower Order Tests)\n```bash\n# Enable strict test ordering - tests wait for lower order tests to complete\nbehavex --order-tests-strict --parallel-processes=3 -t=@INTEGRATION\n\n# Strict ordering with custom prefix\nbehavex --order-tests-strict --order-tag-prefix=SEQUENCE --parallel-processes=2\n\n# Note: --order-tests-strict automatically enables --order-tests, so you don't need both\n```\n\n#### Ordering with Parallel Execution\n```bash\n# Order tests and run with parallel processes by scenario\nbehavex --order-tests --parallel-processes=4 --parallel-scheme=scenario\n\n# Order tests and run with parallel processes by feature\nbehavex --order-tests --parallel-processes=3 --parallel-scheme=feature\n\n# Custom order prefix with parallel execution\nbehavex --order-tests --order-tag-prefix=SEQUENCE --parallel-processes=2\n\n# Strict ordering by scenario (tests wait for completion of lower order tests)\nbehavex --order-tests-strict --parallel-processes=4 --parallel-scheme=scenario\n\n# Strict ordering by feature\nbehavex --order-tests-strict --parallel-processes=3 --parallel-scheme=feature\n```\n\n### Understanding Regular vs Strict Ordering\n\n#### Regular Ordering (`--order-tests`)\n- Tests are **sorted** by order tags but can run **simultaneously** if parallel processes are available\n- Example: With 5 parallel processes and tests `@ORDER_001`, `@ORDER_002`, `@ORDER_003`, all three tests start at the same time\n- **Faster execution** but **less predictable** completion order\n- Best for: Performance optimization, general prioritization\n\n#### Strict Ordering (`--order-tests-strict`)\n- Tests **wait** for all lower-order tests to **complete** before starting\n- Example: `@ORDER_002` tests won't start until all `@ORDER_001` tests are finished\n- **Slower execution** but **guaranteed** sequential completion\n- Best for: Setup/teardown sequences, data dependencies, strict test dependencies\n\n**Performance Comparison:**\n```bash\n# Scenario: 6 tests with ORDER_001, ORDER_002, ORDER_003 tags and 3 parallel processes\n\n# Regular ordering (--order-tests):\n# Time 0: ORDER_001, ORDER_002, ORDER_003 all start simultaneously\n# Total time: ~1 minute (all tests run in parallel)\n\n# Strict ordering (--order-tests-strict):\n# Time 0: Only ORDER_001 tests start\n# Time 1: ORDER_001 finishes → ORDER_002 tests start\n# Time 2: ORDER_002 finishes → ORDER_003 tests start\n# Total time: ~3 minutes (sequential execution)\n```\n\n### Using Custom Order Prefixes\n\nYou can customize the order tag prefix to match your team's naming conventions:\n\n```bash\n# Using PRIORITY prefix\nbehavex --order-tests --order-tag-prefix=PRIORITY\n\n# Now use tags like @PRIORITY_001, @PRIORITY_010, etc.\n```\n\n```gherkin\n@PRIORITY_001\nScenario: High priority scenario\n    Given I need to run this first\n\n@PRIORITY_050\nScenario: Medium priority scenario\n    Given this can run after high priority\n\n@PRIORITY_100\nScenario: Low priority scenario\n    Given this runs last\n```\n\n### Feature-Level Ordering\n\nWhen using `--parallel-scheme=feature`, the ordering is determined by ORDER tags placed directly on the feature itself:\n\n```gherkin\n@ORDER_001\nFeature: Database Setup Feature\n    Scenario: Create database schema\n        Given I create the database schema\n\n    Scenario: Insert initial data\n        Given I insert the initial data\n\n# This entire feature will be ordered as ORDER_001 (tag on the feature)\n\n@ORDER_002\nFeature: Application Tests Feature\n    Scenario: Test user login\n        Given I test user login\n\n# This entire feature will be ordered as ORDER_002 (tag on the feature)\n\nFeature: Unordered Feature\n    Scenario: Some test\n        Given I perform some test\n\n# This feature has no ORDER tag, so it gets the default order 9999\n```\n\n## Test Execution Reports\n\n### JSON Report\nContains information about test scenarios and execution status. This is the base report generated by BehaveX, which is used to generate the HTML report. Available at:\n```bash\n\u003coutput_folder\u003e/report.json\n```\n\n### HTML Report\nA friendly test execution report containing information related to test scenarios, execution status, evidence, and metrics. Available at:\n```bash\n\u003coutput_folder\u003e/report.html\n```\n\n### JUnit Report\nOne JUnit file per feature, available at:\n```bash\n\u003coutput_folder\u003e/behave/*.xml\n```\nThe JUnit reports have been replaced by the ones generated by the test wrapper, just to support muting tests scenarios on build servers\n\n## Attaching Images to the HTML Report\n\nYou can attach images or screenshots to the HTML report using your own mechanism to capture screenshots or retrieve images. Utilize the **attach_image_file** or **attach_image_binary** methods provided by the wrapper.\n\nThese methods can be called from hooks in the `environment.py` file or directly from step definitions.\n\n### Example 1: Attaching an Image File\n```python\nfrom behavex_images import image_attachments\n\n@given('I take a screenshot from the current page')\ndef step_impl(context):\n    image_attachments.attach_image_file(context, 'path/to/image.png')\n```\n\n### Example 2: Attaching an Image Binary\n```python\nfrom behavex_images import image_attachments\nfrom behavex_images.image_attachments import AttachmentsCondition\n\ndef before_all(context):\n    image_attachments.set_attachments_condition(context, AttachmentsCondition.ONLY_ON_FAILURE)\n\ndef after_step(context, step):\n    image_attachments.attach_image_binary(context, selenium_driver.get_screenshot_as_png())\n```\n\nBy default, images are attached to the HTML report only when the test fails. You can modify this behavior by setting the condition using the **set_attachments_condition** method.\n\n![Test Execution Report](https://github.com/abmercado19/behavex-images/blob/master/behavex_images/img/html_test_report.png?raw=true)\n![Test Execution Report](https://github.com/abmercado19/behavex-images/blob/master/behavex_images/img/html_test_report_2.png?raw=true)\n![Test Execution Report](https://github.com/abmercado19/behavex-images/blob/master/behavex_images/img/html_test_report_3.png?raw=true)\n\nFor more information, check the [behavex-images](https://github.com/abmercado19/behavex-images) library, which is included with BehaveX 3.3.0 and above.\n\nIf you are using BehaveX \u003c 3.3.0, you can still attach images to the HTML report by installing the **behavex-images** package with the following command:\n\n\u003e pip install behavex-images\n\n## Attaching Additional Execution Evidence to the HTML Report\n\nProviding ample evidence in test execution reports is crucial for identifying the root cause of issues. Any evidence file generated during a test scenario can be stored in a folder path provided by the wrapper for each scenario.\n\nThe evidence folder path is automatically generated and stored in the **\"context.evidence_path\"** context variable. This variable is updated by the wrapper before executing each scenario, and all files copied into that path will be accessible from the HTML report linked to the executed scenario.\n\n## Test Logs per Scenario\n\nThe HTML report includes detailed test execution logs for each scenario. These logs are generated using the **logging** library and are linked to the specific test scenario. This feature allows for easy debugging and analysis of test failures.\n\n## Metrics and Insights\n\nThe HTML report provides a range of metrics to help you understand the performance and effectiveness of your test suite. These metrics include:\n\n* **Automation Rate**: The percentage of scenarios that are automated.\n* **Pass Rate**: The percentage of scenarios that have passed.\n* **Steps Execution Counter and Average Execution Time**: These metrics provide insights into the execution time and frequency of steps within scenarios.\n\n## Dry Runs\n\nBehaveX enhances the traditional Behave dry run feature to provide more value. The HTML report generated during a dry run can be shared with stakeholders to discuss scenario specifications and test plans.\n\nTo execute a dry run, use the `--dry-run` argument:\n\n```bash\nbehavex --dry-run\nbehavex -t=@TAG --dry-run\n```\n\nFor advanced tag filtering in dry runs, see the [Tag Expressions](#tag-expressions) section.\n\n## Muting Test Scenarios\n\nIn some cases, you may want to mute test scenarios that are failing but are not critical to the build process. This can be achieved by adding the @MUTE tag to the scenario. Muted scenarios will still be executed, but their failures will not be reported in the JUnit reports. However, the execution details will be visible in the HTML report.\n\n## Handling Failing Scenarios\n\n### @AUTORETRY Tag\n\nFor scenarios that are prone to intermittent failures or are affected by infrastructure issues, you can use the @AUTORETRY tag. This tag enables automatic re-execution of the scenario in case of failure.\n\nYou can also specify the number of retries by adding the total retries as a suffix in the @AUTORETRY tag. For example, @AUTORETRY_3 will retry the scenario 3 times if the scenario fails.\n\nThe re-execution will be performed right after a failing execution arises, and the latest execution is the one that will be reported.\n\n### Rerunning Failed Scenarios\n\nAfter executing tests, if there are failing scenarios, a **failing_scenarios.txt** file will be generated in the output folder. This file allows you to rerun all failed scenarios using the following command:\n\n\u003e behavex -rf=./\u003cOUTPUT_FOLDER\\\u003e/failing_scenarios.txt\n\nor\n\n\u003e behavex --rerun-failures=./\u003cOUTPUT_FOLDER\\\u003e/failing_scenarios.txt\n\nTo avoid overwriting the previous test report, it is recommended to specify a different output folder using the **-o** or **--output-folder** argument.\n\nNote that the **-o** or **--output-folder** argument does not work with parallel test executions.\n\n## Displaying Progress Bar in Console\n\nWhen running tests in parallel, you can display a progress bar in the console to monitor the test execution progress. To enable the progress bar, use the **--show-progress-bar** argument:\n\n```bash\nbehavex --parallel-processes=3 --show-progress-bar\nbehavex -t=@TAG --parallel-processes=3 --show-progress-bar\n```\n\nFor advanced tag filtering with progress bar, see the [Tag Expressions](#tag-expressions) section.\n\nIf you are printing logs in the console, you can configure the progress bar to display updates on a new line by adding the following setting to the BehaveX configuration file:\n\n\u003e [progress_bar]\n\u003e\n\u003e print_updates_in_new_lines=\"true\"\n\n## Allure Reports Integration\n\nBehaveX provides integration with Allure, a flexible, lightweight multi-language test reporting tool. The Allure formatter creates detailed and visually appealing reports that include comprehensive test information, evidence, and categorization of test results.\n\n**Note**: Since BehaveX is designed to run tests in parallel, the Allure formatter processes the consolidated `report.json` file after all parallel test executions are completed. This ensures that all test results from different parallel processes are properly aggregated before generating the final Allure report.\n\n### Prerequisites\n\n1. Install Allure on your system. Please refer to the [official Allure installation documentation](https://docs.qameta.io/allure/#_installing_a_commandline) for detailed instructions for your operating system.\n\n### Using the Allure Formatter\n\nTo generate Allure reports, use the `--formatter` argument to specify the Allure formatter:\n\n```bash\nbehavex --formatter=behavex.outputs.formatters.allure_behavex_formatter:AllureBehaveXFormatter\nbehavex -t=@TAG --formatter=behavex.outputs.formatters.allure_behavex_formatter:AllureBehaveXFormatter\n```\n\nBy default, the Allure results will be generated in the `output/allure-results` directory. You can specify a different output directory using the `--formatter-outdir` argument:\n\n```bash\nbehavex -t=@TAG --formatter=behavex.outputs.formatters.allure_behavex_formatter:AllureBehaveXFormatter --formatter-outdir=my-allure-results\n```\n\nFor advanced tag filtering with Allure reports, see the [Tag Expressions](#tag-expressions) section.\n\n### Attaching Screenshots and Evidence to Allure Reports\n\nWhen using Allure reports, you should continue to use the same methods for attaching screenshots and evidence as described in the sections above:\n\n- **For screenshots**: Use the methods described in [Attaching Images to the HTML Report](#attaching-images-to-the-html-report) section. The `attach_image_file()` and `attach_image_binary()` methods from the `behavex_images` library will automatically work with Allure reports.\n\n- **For additional evidence**: Use the approach described in [Attaching Additional Execution Evidence to the HTML Report](#attaching-additional-execution-evidence-to-the-html-report) section. Files stored in the `context.evidence_path` will be automatically included in the Allure reports.\n\nThe evidence and screenshots attached using these methods will be seamlessly integrated into your Allure reports, providing comprehensive test execution documentation.\n\n### Viewing Allure Reports\n\nAfter running the tests, you can generate and view the Allure report using the following commands:\n\n```bash\n# Serve the report (opens in a browser)\nallure serve output/allure-results\n\n# Or... generate a single HTML file report\nallure generate output/allure-results --output output/allure-report --clean --single-file\n\n# Or... generate a static report\nallure generate output/allure-results --output output/allure-report --clean\n```\n\n### Disabling Log Attachments\nBy default, `scenario.log` files are attached to each scenario in the Allure report. You can disable this by passing the `--no-formatter-attach-logs` argument:\n```bash\nbehavex --formatter behavex.outputs.formatters.allure_behavex_formatter:AllureBehaveXFormatter --no-formatter-attach-logs\n```\n\n## Utilities\n\nBehaveX includes additional utility scripts in the `scripts/` folder to help with common tasks:\n\n### HTML Report Generator\n\nGenerate HTML reports from existing `report.json` files without re-running tests:\n\n```bash\n# Generate HTML in the same directory as the JSON file\npython scripts/generate_html_from_json.py output/report.json\n\n# Generate HTML in a specific directory\npython scripts/generate_html_from_json.py output/report.json my_reports/\n\n# Works with any BehaveX JSON report\npython scripts/generate_html_from_json.py /path/to/old_execution/report.json\n```\n\nThis utility is helpful when you want to:\n- Regenerate HTML reports after code changes\n- Create reports from archived test results\n- Generate reports in different locations without re-running tests\n\n## Show Your Support\n\n**If you find this project helpful or interesting, we would appreciate it if you could give it a star** (:star:). It's a simple way to show your support and let us know that you find value in our work.\n\nBy starring this repository, you help us gain visibility among other developers and contributors. It also serves as motivation for us to continue improving and maintaining this project.\n\nThank you in advance for your support! We truly appreciate it.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhrcorval%2Fbehavex","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fhrcorval%2Fbehavex","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhrcorval%2Fbehavex/lists"}