# DamageBDD Alongside Existing Testing Tools Compare the workflow and evidence requirements of a DamageBDD evaluation without assuming zero maintenance or universal coverage. Canonical HTML: ## Evaluate the workflow, not a universal winner DamageBDD connects human-readable acceptance scenarios to execution and inspectable reports. Existing unit, API, browser and performance tools can remain part of a team's workflow. Whether adopting DamageBDD helps depends on the requirements, supported steps, integration effort and evidence needed. | Concern | DamageBDD evaluation | Compare with your existing process | | --- | --- | --- | | Shared requirements | Can stakeholders review the Gherkin scenario? | Is the expected behaviour already clear and versioned? | | Execution coverage | Are the required steps implemented and configured? | Which tools already exercise the target well? | | Maintenance | How much custom step and fixture work is required? | What is the actual maintenance cost today? | | Result identity | Can a report be linked to inputs and a release? | Can a reviewer reproduce the same link now? | | CI integration | Can the API run fit the pipeline's auth and failure handling? | How are results and retries handled today? | | Performance | What throughput and resource cost does a measured run show? | Compare under the same workload and environment | | Payment | Which execution or work unit is priced and confirmed? | Keep commercial acceptance and settlement explicit | Supported steps still have code and operational dependencies. New behaviours may need additional implementations. No zero-maintenance, universal test coverage or measured superiority claim follows from using Gherkin. Start with [one API journey](api_journey_assurance.md) and consult the [module reference](../modules/index.md). Use the [capability matrix](features_current.md) for status and the [payment guide](../payments.md) for any paid integration.