FNB Mainframe Mock with Robot framework on HyperExecute

Getting Started

TestMu AI (Formerly LambdaTest) is the world's first full-stack AI Agentic Quality Engineering platform that empowers teams to test intelligently, smarter, and ship faster. Built for scale, it offers a full-stack testing cloud with 10K+ real devices and 3,000+ browsers. With AI-native test management, MCP servers, and agent-based automation, TestMu AI supports Selenium, Appium, Playwright, and all major frameworks.

With TestMu AI (Formerly LambdaTest), you can run Java TestNG Selenium tests at scale using HyperExecute smart test orchestration. This sample shows how to configure Java + TestNG with HyperExecute to run on the TestMu AI cloud.

• Sign up on TestMu AI (Formerly LambdaTest).
• Follow the TestMu AI Documentation for the full setup walkthrough.

Robot Framework test suite that exercises a mocked First National Bank (FNB) mainframe "green screen" application, designed to run locally or be orchestrated in parallel by TestMu AI HyperExecute. The base suite (tests/01-05) needs no real z/OS host or 3270 emulator binary at all; the tests/06-09 TN3270 suite is a second, separate mock that talks the real TN3270 protocol and does need the s3270 emulator binary (installed automatically in yaml/hyperexecute-mainframe-testing.yaml's pre step). tests/10 is a third track that drives the same TN3270 protocol with a real, visible x3270 GUI window instead of headless s3270, so it needs an X display too — it renders on the display HyperExecute's captureScreenRecordingForScenarios already provisions for that VM, rather than a separate Xvfb of our own.

How it works

• mock_server/fnb_mock_server.py is a small in-memory TCP server that speaks a simplified, Telnet-friendly text protocol standing in for a CICS-style 3270 mainframe: connect, send a transaction code (LOGON, INQUIRY, TRANSFER, HISTORY, PF7, PF8, PF3, CLEAR), get back a "screen".
• The Robot Framework suites drive it through libs/fnb_client.py, a tiny custom library built on raw sockets. (Robot Framework ships a built-in Telnet library, but it depends on the standard-library telnetlib module, which was removed in Python 3.13/PEP 594 — so a self-contained socket client keeps this working on any current Python.) It synchronizes on a sentinel line (@@SCREEN-END@@) instead of fixed sleeps.
• Each TCP connection gets a fresh, independent copy of account/user data, so tests never leak state into each other even when run back-to-back against the same mock server process.
• mock_server/fnb_mock_tn3270.py is a second, separate mock: a real TN3270 host (actual Telnet option negotiation + 3270 data stream — EBCDIC, SBA/SF/IC orders, the works), simulating a small "VBank" retail banking app (LOGON → MAIN MENU → Balance Inquiry / Funds Transfer / Mini Statement). It's driven by the standard robotframework-mainframe3270 library instead of a custom client, so the suites in tests/06_tn3270_*.robot onward use the same keywords (Open Connection, Write Bare In Position, Send Enter, Page Should Contain String, ...) a real mainframe QA team would use against an actual z/OS host. It requires the x3270/s3270 emulator binary on PATH (see "Run on HyperExecute" below) — headless (visible=${False}), so no X server is needed.
• mock_server/fnb_mock_tnX3270.py is a third mock: the exact same protocol implementation as fnb_mock_tn3270.py (it imports and reuses it), just listening on its own port (3272) so it can run at the same time as the headless mock. tests/10_x3270_gui_banking.robot, via resources/tn3270_gui_common.resource (visible=${True}), drives it with a real x3270 GUI window instead of headless s3270, and takes a screenshot after each transaction. Because x3270 is a real X11 app, this needs a display and X core fonts (see "Run on HyperExecute" below) — but not a separate Xvfb, since HyperExecute already provisions one for captureScreenRecordingForScenarios, and standing up a second, unrecorded display would just make the scenario video blank.

Run locally

pip install -r requirements.txt
python mock_server/fnb_mock_server.py &     # starts on 127.0.0.1:3271
robot --outputdir results tests

Open results/report.html / results/log.html afterwards.

The tests/06_tn3270_*.robot suites additionally need a 3270 emulator binary (x3270/s3270/ws3270) installed and on PATH, plus mock_server/fnb_mock_tn3270.py running on 127.0.0.1:3270. This repo's yaml/hyperexecute-mainframe-testing.yaml installs that binary automatically on HyperExecute's Linux VMs (apt-get install -y s3270 — note this is a separate Debian/Ubuntu package from x3270, not bundled inside it, and it's the one that actually matters here since visible=${False} runs headless); on Windows there is no equivalent one-line install, so those four suites are written and intended to be verified via HyperExecute rather than on a local Windows machine.

tests/10_x3270_gui_banking.robot additionally needs the GUI x3270 package plus an X display for it to render on, and mock_server/fnb_mock_tnX3270.py running on 127.0.0.1:3272. It's written and intended to be verified via HyperExecute, which already provides a display via captureScreenRecordingForScenarios — there's no clean local equivalent on Windows/macOS, and on Linux you'd need your own X session or Xvfb plus the X core fonts x3270 needs (see below).

Run on HyperExecute

./hyperexecute.exe --config yaml/hyperexecute-mainframe-testing.yaml --user <email> --key <access_key>

hyperexecute-mainframe-testing.yaml:

• captureScreenRecordingForScenarios: true: records a native video per scenario on HyperExecute's Linux VMs, and — just as importantly for the GUI track — is what provisions the X display that x3270 renders on. No DISPLAY env var or Xvfb of our own; standing up a second, unrecorded display would just make x3270 invisible to the recorder.
• env: MAINFRAME_HOST/MAINFRAME_PORT/MAINFRAME_GUI_PORT/MAINFRAME_USER/ MAINFRAME_PASS configure both TN3270 mocks' bind ports/credentials and what the RF suites connect with; DEBIAN_FRONTEND=noninteractive keeps apt-get install from blocking on a prompt.
• pre: installs s3270 (headless emulator), x3270 (GUI emulator), and the X core-font packages x3270 needs (xfonts-base, xfonts-100dpi, xfonts-75dpi, fonts-dejavu-core, x11-utils, x11-xserver-utils) — x3270 uses old-style X11 bitmap fonts, and the recorded display's default font path omits them, so without these it exits immediately instead of rendering. Then installs the Python requirements. background starts all three mock servers on each HyperExecute VM before tests run.
• testDiscovery: finds every tests/*.robot file (both the plain-socket suites and the TN3270 ones).
• autosplit + concurrency: 2: distributes those files across parallel HyperExecute machines automatically.
• testRunnerCommand: registers the installed font dirs on the VM's display (xset +fp / xset fp rehash, harmless no-ops for non-GUI suites) then runs each discovered file with robot, writing a uniquely named output_*.xml/log_*.html per file into results/.
• uploadArtefacts / report / partialReports: pulls the Robot Framework XML/HTML output back and renders it on the HyperExecute dashboard.

Project layout

hyperexecute-mainframe-testing.yaml            Orchestrator config (see above)
requirements.txt             Python deps (robotframework, robotframework-mainframe3270)
mock_server/
  fnb_mock_server.py         Mock FNB mainframe (LOGON/INQUIRY/TRANSFER/HISTORY) - simplified ASCII protocol
  fnb_mock_tn3270.py         Mock VBank mainframe - real TN3270 protocol (Telnet negotiation + 3270 data stream)
  fnb_mock_tnX3270.py        Same protocol as fnb_mock_tn3270.py, own port (3272), for the x3270 GUI track
libs/
  fnb_client.py              Custom RF library for fnb_mock_server.py: raw-socket client (Telnet-free)
resources/
  variables.resource         fnb_mock_server.py: host/port/credentials/timeouts
  common.resource            fnb_mock_server.py: connect / send-transaction / logon keywords
  fnb_screens.resource       fnb_mock_server.py: business-level keywords (Go To Account Inquiry, ...)
  tn3270_variables.resource  fnb_mock_tn3270.py: host/port/credentials + screen field coordinates
  tn3270_common.resource     fnb_mock_tn3270.py: connect/logon/navigation keywords (Mainframe3270Library, headless)
  tn3270_gui_variables.resource  fnb_mock_tnX3270.py: adds the GUI port, reuses tn3270_variables.resource
  tn3270_gui_common.resource     fnb_mock_tnX3270.py: connect/logon/navigation keywords (visible=True + screenshots)
tests/
  01_login.robot             fnb_mock_server.py: logon success/failure, lockout after 3 bad attempts
  02_account_inquiry.robot   fnb_mock_server.py: balance lookup, ownership enforcement
  03_funds_transfer.robot    fnb_mock_server.py: transfers, insufficient funds, limits, bad accounts
  04_transaction_history.robot  fnb_mock_server.py: history listing + PF7/PF8 paging
  05_negative_session.robot  fnb_mock_server.py: unauthenticated access, timeout, bad PF key, logoff
  06_tn3270_logon.robot      fnb_mock_tn3270.py: real TN3270 LOGON screen
  07_tn3270_account_inquiry.robot  fnb_mock_tn3270.py: balance inquiry
  08_tn3270_funds_transfer.robot   fnb_mock_tn3270.py: transfers + insufficient-funds check
  09_tn3270_mini_statement.robot   fnb_mock_tn3270.py: mini statement
  10_x3270_gui_banking.robot       fnb_mock_tnX3270.py: full banking flow via real x3270 GUI, with screenshots
results/                     Robot Framework output (gitignored)

Test accounts

mock_server/fnb_mock_server.py (ASCII protocol, tests/01-05):

Userid	Password	Accounts	Notes
JSMITH01	Passw0rd1	1001, 1002, 1003	Primary test user
MDOE0002	Passw0rd2	2001	Used for ownership checks
LOCKED03	Passw0rd3	3001	Pre-locked account

mock_server/fnb_mock_tn3270.py / fnb_mock_tnX3270.py (real TN3270, headless tests/06-09 and GUI tests/10 respectively — same protocol, same accounts) — single global login, taken from MAINFRAME_USER/MAINFRAME_PASS (default MOCKUSER/MOCKPASS):

Account	Owner	Balance	Statement history
1001	JOHN Q PUBLIC	5,250.75	5 transactions
1002	JANE A SMITH	12,900.00	none
1003	ACME CORP LLC	847,213.42	none

Extending

• For fnb_mock_server.py: add new screens/transactions to the mock, add a matching keyword to resources/fnb_screens.resource, then write a new tests/NN_*.robot file.
• For fnb_mock_tn3270.py: add a new screen function + state transition to the mock, note its field coordinates in resources/tn3270_variables.resource, add a navigation keyword to resources/tn3270_common.resource, then write a new tests/NN_tn3270_*.robot file.
• For the GUI track: new screens/state live in fnb_mock_tn3270.py / tn3270_variables.resource as above (fnb_mock_tnX3270.py just reuses that logic on port 3272) — add the matching keyword to resources/tn3270_gui_common.resource (with a Take Screenshot call) and write the test against tests/10_x3270_gui_banking.robot or a new tests/NN_x3270_*.robot file.
• Either way, HyperExecute's testDiscovery picks up new tests/*.robot files automatically — no YAML change needed.

Contributions

Contributions are welcome. Open an issue to discuss your idea before submitting a pull request. When reporting bugs, include your Java version, OS, and TestNG version.

TestMu AI (Formerly LambdaTest) Community

Connect with testers and developers in the TestMu AI Community. Ask questions, share what you are building, and discuss best practices in test automation and DevOps.

TestMu AI (Formerly LambdaTest) Certifications

Earn free TestMu AI Certifications for testers, developers, and QA engineers. Validate your skills in Selenium, Cypress, Playwright, Appium, Espresso and more. Industry-recognized, shareable on LinkedIn, and built by practitioners, not marketers.

Learning Resources by TestMu AI (Formerly LambdaTest)

Learn modern testing through tutorials, guides, videos, and weekly updates:

• TestMu AI Blog
• TestMu AI Learning Hub
• TestMu AI on YouTube
• TestMu AI Newsletter

LambdaTest is Now TestMu AI

On January 12, 2026, LambdaTest evolved to TestMu AI, the world's first fully autonomous Agentic AI Quality Engineering Platform.

Same team. Same infrastructure. Same customer accounts. All existing LambdaTest logins, scripts, capabilities, and integrations continue to work without change.

👉 Find the new home for LambdaTest.

How LambdaTest Evolved into TestMu AI

In 2017, we launched LambdaTest with a simple mission: make testing fast, reliable, and accessible. As LambdaTest grew, we expanded into Test Intelligence, Visual Regression Testing, Accessibility Testing, API Testing, and Performance Testing, covering the full depth of the testing lifecycle.

As software development entered the AI era, testing had to evolve, too. We rebuilt the architecture to be AI-native from the ground up, with autonomous agents that plan, author, execute, analyze, and optimize tests while keeping humans in the loop. The platform integrates with your repos, CI, IDEs, and terminals, continuously learning from every code change and development signal.

That evolution earned a new name: TestMu AI, built for an AI-first future of quality engineering. TestMu is not a new name for us. It is the name of our annual community conference, which has brought together 100,000+ quality engineers to discuss how AI would reshape testing, long before that became an industry norm.

What started as a high-performance cloud testing platform has transformed into an AI-native, multi-agent system powering a connected, end-to-end quality layer. That evolution defined a new identity: LambdaTest evolved into TestMu AI, built for an AI-first future of quality engineering.

Support

Got a question? Email support@testmuai.com or chat with us 24x7 from our chat portal.