OpenText • Test automation
Functional Testing for Developers is the shift-left companion to Functional Testing and IDE-native authoring, BDD-friendly frameworks, and pipeline integration for developer-led QA. Merito designs the framework.
Merito sells OpenText Functional Testing for Developers and delivers IDE-native authoring, framework design, and CI/CD integration for teams shifting functional testing left into developer workflows.
What it is
OpenText Functional Testing for Developers (formerly LeanFT under Micro Focus) is the shift-left edition of Functional Testing designed for developers authoring tests inside their IDE. It supports Python, Java in IntelliJ and Eclipse, C# in Visual Studio, and BDD frameworks like Cucumber and SpecFlow so tests live alongside application code and run in the same pipeline. Python authoring is the modernization story. Engineers code around edge cases and reach for AI assistants in a language the entire industry already speaks, instead of fighting low-code or no-code authoring surfaces.
The value of Functional Testing for Developers is not replacing Functional Testing; it is complementing it. SDET teams and developer-led QA programs that want to own test code the same way they own production code use Functional Testing for Developers as the authoring environment, while traditional QA teams continue with Functional Testing for broader UI and legacy coverage.
Merito's engagement focuses on the developer workflow and where tests live in source control, how they run in CI, how results surface in code review, and how shared object repositories stay consistent between developer-authored and QA-authored automation.
Ideal use cases
What it is best at
Tests are authored as real code in standard IDEs, so every IDE-integrated AI assistant works on day one. Claude (via Claude Code and IDE plug-ins), OpenAI Codex and ChatGPT IDE integrations, GitHub Copilot, Cursor, JetBrains AI Assistant, and similar engines all produce real Python, Java, C#, or JavaScript test code rather than proprietary low-code blocks. AI productivity gains land directly on the automation framework.
Native Python support lets engineers code around edge cases instead of fighting low-code or no-code limits. Engineers use AI assistants in a language they already know, integrate freely with the broader Python ecosystem, and skip fragile drag-and-drop authoring.
Tests written in Python, Java, C#, or JavaScript inside IntelliJ, Eclipse, or Visual Studio live in the same repo as application code and run in the same pipeline.
Object recognition and application support come from the same engine that powers Functional Testing, so coverage stays consistent across developer and QA teams (200+ enterprise technologies including SAP, Salesforce, Oracle Cerner, Epic EHR, mainframe, and web).
Cucumber, SpecFlow, and JBehave integrations produce tests readable by product owners and business analysts without translating away from engineering workflows.
Core capabilities
Tests authored inside the developer's IDE in Python, Java, C#, or JavaScript, stored in source control, and reviewed as code.
Python authoring
Engineers script around edge cases in Python, use AI assistants in a familiar language, and tap the broader Python ecosystem when scripts need it. No low-code or no-code lock-in.
IntelliJ and Eclipse
Java authoring with plug-ins providing object spy, recording, and debugging.
Visual Studio
C# authoring with full .NET support and familiar developer tooling.
JavaScript support
TypeScript and JavaScript options for teams standardizing on front-end tooling.
BDD and xUnit frameworks so tests integrate naturally into developer workflows.
Cucumber and SpecFlow
Business-readable BDD scenarios that map to step definitions.
JUnit, TestNG, NUnit, xUnit
Native xUnit frameworks that developers already use for unit testing.
JBehave
Additional BDD option for Java teams preferring behavior-first authoring.
Tests run in CI alongside builds and report back into the same tooling as unit tests.
Jenkins, Azure DevOps, GitHub Actions, GitLab CI
Build agents execute functional tests as part of the same pipeline that runs unit tests.
Result formats
JUnit XML, Allure, and native reporters so results plug into existing dashboards.
Core SDP integration
Results flow into Core Software Delivery Platform alongside QA-authored Functional Testing runs.
Where it fits in the stack
Deployment and implementation
Licensing and packaging
Functional Testing for Developers
Per-developer seats for IDE-authored functional automation.
Best for: Development teams adopting shift-left QA with functional coverage.
Merito services
Merito sells licenses and the delivery work around them. Pick the service that matches where you are in the lifecycle.
IDE-native framework architecture, BDD patterns, and CI pipeline wiring.
Explore service02Developer-authored tests wired into release pipelines for gating.
Explore service03LeanFT to Functional Testing for Developers transitions for existing customers.
Explore service04Named engineer, priority SLAs, and release-time coverage for Functional Testing for Developers in production.
Explore service05Developer-focused training on framework design, BDD, and CI integration.
Explore service06Merito-placed SDETs embedded with development teams adopting shift-left QA.
Explore serviceFunctional Testing for Developers licensing
Merito sells OpenText Functional Testing for Developers and delivers the IDE-native framework design, BDD selection, and CI wiring that turns shift-left into real pipeline gating.
Merito point of view
Merito has seen customers buy Functional Testing for Developers expecting SDET productivity gains and find that developers never adopted the tool because ownership of the functional-test suite was unclear. The product is fine; the adoption problem is the framework and ownership model. Developer-authored tests require developer-owned review cycles and real CI pipeline consequences.
Merito recommends Functional Testing for Developers alongside Functional Testing when an SDET team and a traditional QA team coexist. The two editions share the object model, so coverage stays consistent. For teams going pure OSS (Playwright, Cypress), Merito delivers those paths too. The decision is about skill depth and licensing posture, not product quality.
BDD frameworks only pay off if product owners and business analysts actually read the scenarios. If they do not, keep the stack simpler with JUnit or NUnit. BDD for its own sake is overhead.
What buyers usually underestimate
Related from Merito
Related solutions
Related services
Related products
Frequently Asked Questions
Consultation request
Share the development teams in scope and your existing Functional Testing footprint. A Merito shift-left specialist follows up within one business day.
IDE-native
Developers author in IntelliJ, Eclipse, or Visual Studio. Tests are reviewed as code and run in the same pipeline as unit tests.
Shared engine
Object recognition and application support come from the same engine as Functional Testing, so teams share repositories instead of duplicating.
Next step
A Merito Functional Testing for Developers engagement starts with one development team, wires tests into their pipeline, and expands once ownership is clear.