fai/chain-studio
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
chain-studio/test/integration
History
flemming-it 68d23ab7dd
Some checks are pending
Security / Security check (push) Waiting to run
Details
refactor: rename app fai_studio -> chain_studio 
Studio is the Ch∆In product's GUI, not a F∆I-vendor app. Rename the
Flutter package, all package: imports, and the build identity across
platforms: linux/windows CMake BINARY_NAME + project, Windows Runner.rc
fields, macOS PRODUCT_NAME / bundle id (ai.flemming.chain.chainStudio) /
.app + scheme BuildableName. Update the client-SDK + flow-editor deps to
their renamed chain_* packages (path + git URL). Company/copyright fields
now read Flemming.AI. flutter analyze: clean.

Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
2026-06-16 17:48:11 +02:00
..
capabilities_test.dart chore(studio): flutter_markdown_plus migration + integration-test scaffold 2026-05-25 13:22:04 +02:00
hub_fixture.dart refactor: rename app fai_studio -> chain_studio 2026-06-16 17:48:11 +02:00
install_install_planned_test.dart chore(studio): RadioGroup migration + second integration test 2026-05-25 14:05:43 +02:00
plugin_theme_test.dart chore(studio): point plugin test at fai_plugins/ instead of fai_modules/ 2026-05-26 01:00:36 +02:00
README.md refactor: rename app fai_studio -> chain_studio 2026-06-16 17:48:11 +02:00

README.md

Integration tests

These tests spin up a real chain serve subprocess against a fresh temp dir and exercise Studio's Hub-facing data layer against it. They cover the "kind of regression that survives unit tests because the system-shape only manifests across the gRPC boundary".

Status

Scaffold. One canonical test (capabilities). The harness is production-quality (proper teardown, idempotent, port-clean) so new tests slot in by importing hub_fixture.dart and calling HubFixture.start() / dispose() in setUp / tearDown.

What's NOT here yet:

  • A full "install dep → run echo → assert title" scenario. The harness can do it (install_module is a real RPC), but building the fixture for module-bundle downloads against a hermetic local registry is its own scaffold. Tracked as follow-up to S-21.
  • Studio-side widget testing against the live hub. The flutter integration_test package supports it (testWidgets + IntegrationTestWidgetsFlutterBinding), but pumping a full StudioApp against a real gRPC channel needs binding.enableSurfaceBindingHack() ceremony we haven't designed yet.

Running

cd chain_studio
flutter test test/integration/

Prereq: a fai binary on PATH or at ../fai_platform/target/release/fai. The harness skips with a clear message when neither exists, so this command does not fail on a fresh checkout — it just reports skipped tests.

To get the binary:

cd ../fai_platform
cargo build --release --bin fai

First-time-start gotcha

A cold chain serve spends its first ~30s building the curated-model database and initialising SQLite migrations. HubFixture.start() waits up to 60s by default; if your local hub takes longer the first time, run chain serve once by hand against any temp FAI_DATA_DIR to warm the per-user cargo / SBOM caches:

FAI_DATA_DIR=/tmp/fai_warmup chain serve --bind 127.0.0.1:0
# wait for "hub started", Ctrl-C

Subsequent integration-test runs are quick.

Not yet wired into CI

.forgejo/workflows/ci.yml doesn't run these yet. Adding them needs an artifact-passing pattern: the platform build job publishes target/release/fai as a CI artifact; the studio test job consumes it. Pattern is straightforward once we want it; it's deferred because we don't yet have enough integration tests to justify the CI runtime.