Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/JonathanHerSa/xolo-api-hub/llms.txt

Use this file to discover all available pages before exploring further.

Every pull request to Xolo API Hub must pass a three-step CI quality gate before it can be merged. The gate exists to keep a mobile codebase maintainable at speed: strict formatting eliminates style debates in reviews, zero-tolerance static analysis catches real bugs before runtime, and a 100% coverage requirement ensures that every line of production logic is exercised by at least one test. These constraints apply equally to contributors and maintainers — no exceptions are made for hotfixes or small patches.

​
CI Pipeline

The quality gate is defined in .github/workflows/qa.yml and runs automatically on every pull request and every push to the main branch. It can also be triggered manually via workflow_dispatch. Flutter is pinned to version 3.32.0 across all CI jobs.
1

Formatting check

dart format --output=none --set-exit-if-changed lib test
This command checks lib/ and test/ for formatting compliance and exits with a non-zero code if any file differs from the canonical dart format output. The CI step will fail immediately if formatting is inconsistent — no files are modified in CI. Run dart format lib test locally to auto-fix formatting before pushing.
2

Static analysis

flutter analyze
Xolo enforces strict analysis with zero issues tolerated. Any warning, info hint, or error produced by the analyzer blocks the pipeline. The analysis options are governed by analysis_options.yaml at the repository root, which extends flutter_lints with additional rules (including the prohibition on print statements).
3

Unit and widget tests with coverage

flutter test --coverage
The full test suite runs and produces a coverage/lcov.info report. This step is followed immediately by the coverage gate (below) in the same CI job.

​
Coverage Gate

After flutter test --coverage completes, the pipeline strips excluded paths from the coverage report using lcov and then checks that 100% of the remaining lines are covered. The gate is implemented directly in qa.yml using a short Python script: 
lcov --remove coverage/lcov.info \
  '**/*.g.dart' \
  'lib/data/local/tables.dart' \
  'lib/l10n/*' \
  -o coverage/lcov.info
After stripping, the script reads LF: (lines found) and LH: (lines hit) totals from coverage/lcov.info, computes the percentage, and raises a SystemExit if the result is below 100%. A passing run prints output like: 
Coverage: 100.0% (847/847)
Any value below 100.0% aborts the build with a message showing the exact shortfall.

​
Coverage Exclusions

The following paths are stripped from the coverage report before the gate is evaluated. Code in these paths is not required to have test coverage:
Excluded pathReason
**/*.g.dartDrift-generated code — auto-generated from tables.dart by build_runner; not hand-authored logic
lib/data/local/tables.dartDrift schema definitions — declarative table structures with no executable business logic
lib/l10n/*Generated localization files — produced by flutter gen-l10n from ARB sources
Everything else — all hand-written Dart in lib/ — must be covered at 100%.

​
Test Organization

The test/ directory mirrors the lib/ source structure. Tests are organized by architectural layer:
Tests for pure, framework-independent logic at the heart of Xolo’s request pipeline:
  • VariableParser — {{variable}} substitution, dynamic built-ins ($timestamp, $guid, $randomInt), and edge cases
  • ScriptExecutor — pre-request and post-request script execution, variable upsert behavior
  • AuthResolverService — inherited auth resolution up the collection/folder hierarchy for all auth types (Bearer, Basic, API Key, OAuth2, AWS Signature, etc.)
  • EncryptionService — AES encryption and decryption used for local backup files
  • CurlParser — cURL command string parsing into structured request objects
  • CodeGenerators — code-snippet generation (Dart, Python, JavaScript, etc.) from request models
  • SecurityService — security profile enforcement (Standard / Hardened / Paranoid)
Tests for the repository implementation, database migrations, and import services:
  • DriftXoloRepository — all repository methods against an in-memory SQLite database
  • Database migration — schema version upgrade paths verified with Drift’s verifyDatabase
  • Entity mappers — round-trip conversion between Drift row types and domain *Entity objects (lib/data/mappers/entity_mappers.dart)
  • PostmanService — Postman Collection v2.1 import, folder/request hierarchy reconstruction
  • OpenApiService — OpenAPI 3.x and Swagger 2.x import, endpoint-to-request mapping
  • ImportManager — format auto-detection and delegation to the appropriate import service
Tests for pure domain services introduced as part of the automation roadmap:
  • AssertionEvaluator — all assertion types (status_code, response_time_ms, json_path_exists, json_path_equals, body_contains) including edge cases such as non-JSON response bodies
  • RunPlanBuilder — collection flattening to an ordered RunPlanItem list for flat, nested, empty, and folder-only collections
  • KeyValuePair — domain value-object equality and serialization
Tests for Riverpod providers and the request execution controller:
  • Provider state transitions — loading, data, and error states for collections, environments, and workspace providers
  • RequestController — request send flow, variable interpolation, script execution order, and history persistence via mocked XoloRepository

​
Running Tests Locally

# Run the full test suite
flutter test

# Run with coverage report (produces coverage/lcov.info)
flutter test --coverage

# Run a single test file
flutter test test/core/variable_parser_test.dart
Run flutter test --coverage locally before pushing. Once the report is generated, inspect uncovered lines with:
lcov --summary coverage/lcov.info
For a browsable HTML report, use genhtml:
genhtml coverage/lcov.info -o coverage/html
open coverage/html/index.html
This lets you spot uncovered lines file-by-file before CI catches them.

​
Release Pipeline

The release workflow is defined in .github/workflows/release.yml and triggers on any tag push matching v* (e.g., v1.0.0). It is structured as two dependent jobs:
  1. quality — calls the qa.yml workflow as a reusable workflow. The release cannot proceed unless every QA step (format, analyze, test, coverage gate) passes first.
  2. build — runs only after quality succeeds. It sets up Java 17 (Zulu distribution), installs Flutter 3.32.0, and builds the release APK: 
    flutter build apk --release
    The resulting app-release.apk (written to build/app/outputs/flutter-apk/) is then attached to a GitHub Release created by softprops/action-gh-release@v2 using the tag name as the release title.
Flutter is pinned to 3.32.0 in the release workflow for the same reason it is pinned in QA — reproducible builds across all environments.

​
Completed Hardening

The following quality improvements are already in place and are maintained by the CI gate on every PR (sourced from docs/quality-gate-plan.md):

Repository layer

XoloRepository / DriftXoloRepository sits between the presentation tier and Drift. No direct Drift access from screens or providers.

Domain entities

*Entity types and round-trip mappers in lib/data/mappers/entity_mappers.dart decouple domain logic from Drift row types.

Modular files

request_tabs, auth_tab, and database.dart have been split into focused, single-responsibility modules.

Internationalization

Full UI coverage via app_en.arb / app_es.arb and AppLocalizations. All user-visible strings are externalized.

221+ unit tests

Core services, providers, DB queries, import/sync flows, and code generators are all covered.

AppLogger

AppLogger replaces all ad-hoc print calls in core services. print is prohibited by lint rules.

go_router navigation

Declarative routing with HomeShell and named routes throughout the app.

CI enforced

The release workflow depends on qa.yml; Flutter is pinned to 3.32.0 in both workflows.
Pull requests that reduce coverage below 100% will be blocked by CI and cannot be merged. Write tests for every new function, method, and branch before submitting your PR. The coverage gate has no override — it must be green.

Build docs developers (and LLMs) love

Get started for freeTalk to us