How BDD‑Driven HTA Automation Boosts Test Coverage and Cuts Costs

Overview

The article explores a project’s shift from manual testing to an automated solution that combines Jest, BDD (Behavior‑Driven Development), and HTA (Headless Test Automation). It explains how this approach improves test efficiency, reduces development cost, and ensures test quality.

Background and Current Situation

Problems of manual testing

Low and unstable coverage due to limited tester resources.

Chaotic test‑case management; many cases exist only in testers’ memory, leading to ambiguous requirements and high communication cost.

Increasing project complexity makes pure manual testing unable to meet fast‑iteration demands.

These issues drive the need for standardized, automated, and systematic testing.

What Is HTA‑Based Automation?

HTA refers to using the Jest framework for unit and integration testing of JavaScript/React applications. Jest offers a simple API, snapshot testing, built‑in assertions, parallel execution, CI integration, and strong community support.

Current Bottlenecks of HTA Automation

Coverage gaps : Relying on manually written test cases makes it difficult to achieve high line (≈90%) and branch (≈70%) coverage, especially for complex business logic.

Rising development cost : Writing HTA cases averages only 2‑3 cases per hour, accounting for about 25% of development effort.

Core Goals of BDD‑Generated HTA

Coverage improvement : Increase line coverage to 90% and branch coverage to 70%.

Cost optimization : Reduce the portion of development cost spent on test case creation from 25% to 5%.

Efficiency boost : Lower manual testing ratio from 20% to 2% and shorten release cycles to within 14 days.

Technical Solution: BDD‑Driven HTA Construction

4.1 BDD Test‑Case Specification

BDD uses natural‑language steps (Given‑When‑Then) to describe behavior, reducing ambiguity and ensuring consistent execution across team members.

Example of a plain test case

Step 1: Click the "Add Adult" button on the SKU module.
Step 1.1: Click the "Add Child" button on the SKU module.
Expected 1: The traveler module shows "Select an adult ticket / Select a child ticket".
Step 2: Click the "Adult1" option.
Step 2.1: Click the "Child1" option.
Expected 2: The traveler module shows "Adult1, Child1".
Step 3: Click the "Add/Select" button.
Expected 3: "Add Traveler" overlay appears.

4.2 Automation Workflow

The workflow consists of four main stages:

Prepare the Jest environment (install dependencies, configure jest.config.js, set up Babel).

Parse BDD scenarios to extract actions, inputs, and expected results.

Convert parsed steps into Jest test code.

Manage mock data and run tests in CI pipelines.

Sample Jest configuration (hta.config.js)

const path = require("path");
const template = require("./template");
module.exports = {
  type: "xtaro-tnt",
  entry: path.join(__dirname, "../dist-crn/xtaro-tnt/src"),
  srcEntry: {
    dev: path.join(__dirname, "../dist/crn-072/src"),
    pipeline: path.join(__dirname, "../dist-crn/xtaro-tnt/src")
  },
  path: {
    dev: path.join(__dirname, "../dist/crn-072"),
    pipeline: path.join(__dirname, "../dist-crn/xtaro-tnt")
  },
  pages: [{
    name: "xxx页面",
    pageName: "new-product-detail",
    template: template.newProductDetail,
    useNpmTest: true
  }]
};

Generated Jest test example

describe("xxx页面", () => {
  let PageComponent;
  beforeEach(async () => {
    global.BoundingClientRect = { height: 1500 };
    global.RequestFolderId = {{mock_data}};
    PageComponent = await render(<div testID="global-testID"><Page /></div>);
    await sleep(1000);
  });
  afterEach(async () => {
    global.RequestFolderId = RequestFolderId;
  });
  it("{5355344}-xxx模块展示逻辑", async () => {
    await expectAttrsExistsAsync(screen, "通用头部模块", { children: ["自营", "xxx景区一日游【xx景区专线】"] });
    await expectAttrsExistsAsync(screen, "a图标", { runnerId: "3_1" });
    const component = await expectAttrsExistsAsync(screen, "a图标", { runnerId: "4_0", children: ["xx产品浮层"] });
    await expectAttrsExistsAsync(screen, "b-右箭头", { runnerId: "8_1" });
    const compB = await expectAttrsExistsAsync(screen, "b-右箭头", { runnerId: "9_0" });
    fireEvent(compB, "click");
    await expectAttrsExistsAsync(screen, "b-浮层", { runnerId: "9_1" });
    await expectAttrsExistsAsync(screen, "global-testID", { children: ["浮层信息1", "浮层信息2", "浮层信息3"] });
    await expectAttrsExistsAsync(screen, "carPopup_close_btn", { runnerId: "11_1" });
    await expectAttrsExistsAsync(screen, "c图标", { runnerId: "12_1" });
    await expectAttrsExistsAsync(screen, "d图标", { runnerId: "13_1" });
  });
});

4.3 Mock Data Management

Mock data is stored centrally in a Git repository and managed through a Mock‑case platform that provides visual editing, real‑time preview via query parameters, and optional NPM package publishing for faster CI execution.

4.4 Test‑Case Platform for Visual Debugging

The platform maps each step’s execution result, shows generated HTA code, and displays error information, helping non‑developer testers locate issues quickly.

Implementation Results

Case study: Scenic Activity Page

Manual HTA: 500 cases, 823 steps, 71% line coverage, 60% branch coverage.

BDD‑generated HTA: 214 cases, 1852 steps, 91% line coverage, 74% branch coverage.

Benefits observed:

Fewer test cases with higher per‑case coverage, reducing maintenance cost.

More detailed steps improve verification quality.

Higher automation coverage lowers the risk of missed defects.

Project‑cycle comparison

Traditional mode: 15.5 days total (10 days development, 5.5 days testing).

Test‑left‑shift mode: 17.5 days total.

BDD‑HTA mode: 14 days total (10 days development, 3.5 days automated testing + 0.5 days manual).

The BDD‑HTA mode shortens the release cycle by ~10% and cuts testing cost by ~15% while improving the developer‑to‑tester effort ratio from 4.4:1 to 7:1.

Release‑Process Refactoring

After BDD‑HTA integration, coverage thresholds (>90% line, >70% branch) are enforced in GitLab CI. Merge requests that do not meet the thresholds are blocked.

Future Plans

Automated collection and ingestion of mock data from user‑behavior recording platforms.

Integrate the test‑case platform into standard CI pipelines to support batch execution and reduce local setup overhead.

Conclusion

The transition from manual testing to BDD‑driven HTA demonstrates that a well‑designed, semantic BDD specification combined with automated HTA generation can simultaneously raise coverage, lower cost, and accelerate releases. Continued improvements in cross‑platform testing and AI‑assisted data generation will further cement automated testing as a core pillar of software quality assurance.