GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — starrocks/fe/fe-testing at main · APIJSON/starrocks

Expand file tree

/

fe-testing

/
Copy path

Directory actions

More options

More options

Directory actions

More options

More options

Latest commit

 

History

History
History
 
 
/

fe-testing

/
Copy path

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
src/main/java/com/starrocks/common/jmockit
src/main/java/com/starrocks/common/jmockit
 
 
README.md
README.md
 
 
build.gradle.kts
build.gradle.kts
 
 
pom.xml
pom.xml
 
 

README.md

Outline

StarRocks Testing Utilities and Mocks

This directory hosts shared test dependencies used across the project: common test code, utilities, fixtures, and mock/stub implementations. The goal is to maximize reuse, keep tests consistent, and reduce duplication.

What lives here

  • Utilities: helpers for assertions, data generation, temporary files/dirs, config parsing, JSON/CSV helpers.
  • Mocks/Stubs/Fakes: lightweight implementations of SPI/core-facing interfaces for isolated tests (e.g., mock connectors, auth providers, catalog services).
  • Fixtures: reusable datasets, schemas, DDLs, and golden files for deterministic tests.
  • Test-only common code: shared abstractions and base classes to simplify test setup/teardown.

Usage

  • Import and reuse helpers instead of duplicating logic in individual test modules.
  • Prefer fakes/stubs for fast unit tests; reserve heavy integrations for dedicated test suites.
  • Keep fixtures small and deterministic; document assumptions in comments.

Guidelines

  • Deterministic: avoid time, randomness, and network unless explicitly controlled.
  • Thread-safe: mocks/utilities should be safe for concurrent tests or document limitations.
  • Minimal coupling: do not reference FE/BE internal classes unless strictly necessary; prefer public APIs/SPI.
  • Clear ownership: place helpers close to their domain but keep them generic and reusable.
  • No secrets: never include real credentials or PII in fixtures or logs.

Non-goals

  • Not a place for production utilities or runtime dependencies.
  • Avoid embedding heavy external services; use in-memory fakes or containers only in dedicated integration tests.

References

  • Test suites: fe/fe-core/src/test/
  • Project docs: https://docs.starrocks.io/
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.