Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Principle:Getgauge Taiko Code Generation

From Leeroopedia
Knowledge Sources
Domains Browser_Automation, Code_Generation
Last Updated 2026-02-12 00:00 GMT

Overview

Technique for automatically generating executable test scripts from recorded interactive browser sessions.

Description

Code generation transforms a sequence of recorded user interactions into a runnable test script or test framework step definitions. This capability bridges the critical gap between exploratory testing (interactive REPL sessions where a tester discovers how an application works) and repeatable automated tests (scripts that can be executed consistently in CI/CD pipelines).

During an interactive REPL session, every successfully executed command is accumulated in an ordered recording list. When the user invokes the code generation command, this recorded sequence is formatted into a complete, self-contained JavaScript script with proper imports, error handling, and cleanup logic. The resulting script can be run directly without any manual editing.

The code generation process handles several important concerns:

  • Import resolution -- The generator analyzes the recorded commands to determine which API functions were used and generates the appropriate import statement. Only the functions that were actually invoked are included in the import, keeping the generated script clean and minimal.
  • Async execution context -- Because browser automation commands are asynchronous, the generated script wraps all commands in an async function with proper await keywords on each command.
  • Error handling -- The generated script includes a try/catch/finally block to ensure that errors are caught and reported, and that the browser is always closed properly in the finally block regardless of whether the test passed or failed.
  • Cleanup guarantees -- The closeBrowser() call is placed in the finally block to prevent orphaned browser processes, which is especially important in CI environments.

For test frameworks like Gauge, the same recording can generate step definition templates that map natural language specifications to automation code. In this mode, lifecycle commands such as openBrowser and closeBrowser are filtered out (since the test framework manages the browser lifecycle), and the remaining commands are wrapped in a Gauge step function template.

Usage

Use code generation in the following scenarios:

  • After an interactive REPL session -- Once you have successfully explored and validated a sequence of interactions against a live browser, use the .code command to convert those interactions into a reusable script.
  • Generating standalone scripts -- The .code command produces a complete JavaScript file that includes openBrowser, all recorded interactions, and closeBrowser with proper error handling.
  • Generating Gauge step definitions -- The .step command produces a Gauge-compatible step definition function, filtering out browser lifecycle commands and wrapping the interaction commands in a step template. This is useful when integrating recorded interactions into a Gauge specification.
  • Rapid test prototyping -- Use the REPL to quickly prototype a test, generate the code, and then refine the generated script by adding assertions, parameterizing values, or restructuring the flow.

Theoretical Basis

Code generation in Taiko follows the Record-Replay pattern, a well-established technique in software testing where user interactions are captured during a recording phase and then replayed automatically during a testing phase.

The process operates in two distinct phases:

Phase 1: Recording

During the interactive REPL session, each successfully executed command is stored in an ordered list along with its API function name and the complete command text as entered by the user. Failed commands are not recorded, ensuring that the generated script only contains commands that are known to work.

Phase 2: Generation

When code generation is invoked, the recorded command list is transformed into source code through a series of steps:

Pseudocode: Code Generation (.code command)

function generateCode(recordedCommands):
    1. EXTRACT unique API names from recorded commands
       e.g., [goto, click, write, press] from the command list

    2. BUILD import statement
       -> const { openBrowser, goto, click, write, press, closeBrowser }
              = require('taiko');

    3. WRAP commands in async execution context
       -> (async () => {
              try {
                  await openBrowser();
                  // ... recorded commands with await ...
              } catch (error) {
                  console.error(error);
              } finally {
                  await closeBrowser();
              }
          })();

    4. FORMAT each recorded command with await prefix
       -> await goto("https://example.com");
       -> await click("Login");
       -> await write("user@example.com");

    5. OUTPUT complete script as valid JavaScript module
Pseudocode: Step Generation (.step command)

function generateStep(recordedCommands, stepText):
    1. FILTER out lifecycle commands
       REMOVE openBrowser, closeBrowser from recorded commands

    2. EXTRACT unique API names from filtered commands

    3. BUILD import statement (without openBrowser/closeBrowser)
       -> const { goto, click, write, press } = require('taiko');

    4. WRAP in Gauge step template
       -> step(stepText, async function() {
              // ... filtered commands with await ...
          });

    5. OUTPUT as valid Gauge step definition

The key distinction between the two generation modes is the scope of responsibility. In standalone script generation, the script owns the entire browser lifecycle (launch, interact, close). In step definition generation, the test framework owns the lifecycle, and the generated code is responsible only for the interaction commands within a single test step.

This separation follows the Single Responsibility Principle: the generated step focuses exclusively on the specific user interaction, while browser lifecycle management is delegated to the framework's hooks or other steps.

Related Pages

Implemented By

Page Connections

Double-click a node to navigate. Hold to expand connections.
Principle
Implementation
Heuristic
Environment