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.
Developers author in IntelliJ, Eclipse or Visual Studio, and the tests run in the application's own CI pipeline. Merito's part is the IDE setup, the BDD framework choice and that pipeline wiring.
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 an optional modernization path that teams adopt when it fits their requirements. Engineers who choose it can code around edge cases and use the broader Python ecosystem.
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 teams that choose to use an IDE-integrated AI assistant can do so, but none is required. Whichever assistant a team picks can produce real Python, Java, C#, or JavaScript test code rather than proprietary low-code blocks.
Native Python support gives engineers a choice. Teams that adopt it can code around edge cases and integrate with the broader Python ecosystem, and AI assistants are an optional extra, never a requirement.
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
Pick the engagement that matches where you are in the lifecycle.
IDE-native framework architecture, BDD patterns, and CI pipeline wiring.
Explore serviceLeanFT to Functional Testing for Developers transitions for existing customers.
Explore serviceNamed engineer, priority SLAs, and release-time coverage for Functional Testing for Developers in production.
Explore serviceDeveloper-focused training on framework design, BDD, and CI integration.
Explore serviceMerito-placed SDETs embedded with development teams adopting shift-left QA.
Explore serviceFunctional Testing for Developers licensing
Developer-authored tests hold up when developers own them, review them as code and see the pipeline fail when they break.
Merito point of view
Functional Testing for Developers often misses its SDET productivity goals because developers never adopt it while ownership of the functional-test suite is 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.
Run 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. Teams going pure OSS with Playwright or Cypress face a different decision, about skill depth and licensing posture rather than 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.