Phase A: generierter Dart-Client + DI-Foundation für Rust-Backend
OpenAPI-Generator-Setup: - tool/generate_api_client.sh: Direkter Aufruf der openapi-generator-cli.jar (Java-CLI statt Dart-build_runner-Integration — vermeidet die analyzer-/source_gen-Version-Hölle mit json_serializable) - tool/fetch_openapi_generator.sh: lädt die JAR (29 MB) nach (gitignored) - openapi/holzleitner.json: Snapshot der Backend-Spec für reproduzierbare Generation - packages/holzleitner_api/: generiertes Dart-Sub-Package (built_value + dio), per path-dep im Haupt-pubspec eingehängt Netzwerk-Layer (lib/data/network/): - BackendConfig: API- und Keycloak-Endpoints für Local-Dev (localhost wegen Keycloak-iss-Claim). - AuthTokenProvider-Schnittstelle. - DevPasswordGrantTokenProvider: Phase-A-Provider via Keycloak password-grant, Token-Caching mit Expiry-Check (Phase B ersetzt das durch flutter_appauth PKCE). - HolzleitnerAuthInterceptor: dynamischer Bearer-Inject pro Request. - HolzleitnerApiFactory: baut die generierte HolzleitnerApi-Klasse mit unserem Interceptor statt der vier Default-Auth-Interceptors. - network_locator.registerNetworking(): get_it-Setup, in main() vor runApp() aufgerufen. Clean-Arch-Scaffolding (lib/data/, lib/domain/): - Verzeichnisstruktur für Phase C+D angelegt (mapper/, repository/, entity/, repository/) — befüllt sich in den Folge-Phasen. Smoke-Test: - tool/smoke_test_api.dart ruft /health (ungeschützt) und /me/cars (mit Bearer) via generiertem Client — grün gegen lokales Backend.
This commit is contained in:
53
packages/holzleitner_api/test/deliveries_api_test.dart
Normal file
53
packages/holzleitner_api/test/deliveries_api_test.dart
Normal file
@ -0,0 +1,53 @@
|
||||
import 'package:test/test.dart';
|
||||
import 'package:holzleitner_api/holzleitner_api.dart';
|
||||
|
||||
|
||||
/// tests for DeliveriesApi
|
||||
void main() {
|
||||
final instance = HolzleitnerApi().getDeliveriesApi();
|
||||
|
||||
group(DeliveriesApi, () {
|
||||
// Setzt das `assigned_car_id` einer Lieferung. `carId: null` löst die Zuordnung wieder. Der Use Case stellt sicher, dass das Fahrzeug zum angemeldeten Account gehört.
|
||||
//
|
||||
//Future<DeliveryResponse> assignCar(String deliveryId, AssignCarRequest assignCarRequest) async
|
||||
test('test assignCar', () async {
|
||||
// TODO
|
||||
});
|
||||
|
||||
// Setzt die Lieferung auf `canceled` — endgültig. Erlaubt aus `active` und `held`.
|
||||
//
|
||||
//Future<DeliveryResponse> cancel(String deliveryId, CancelDeliveryRequest cancelDeliveryRequest) async
|
||||
test('test cancel', () async {
|
||||
// TODO
|
||||
});
|
||||
|
||||
// Schließt die Lieferung ab — `state = completed`. Nur aus `active`.
|
||||
//
|
||||
//Future<DeliveryResponse> complete(String deliveryId) async
|
||||
test('test complete', () async {
|
||||
// TODO
|
||||
});
|
||||
|
||||
// Legt eine neue Notiz an einer Lieferung an. Mindestens eines von `text` und `imageAttachment` muss inhaltlich gefüllt sein (Leerstrings werden serverseitig getrimmt und als leer behandelt).
|
||||
//
|
||||
//Future<DeliveryNoteResponse> createNote(String deliveryId, CreateDeliveryNoteRequest createDeliveryNoteRequest) async
|
||||
test('test createNote', () async {
|
||||
// TODO
|
||||
});
|
||||
|
||||
// Setzt die Lieferung auf `held`. Nur aus `active` zulässig.
|
||||
//
|
||||
//Future<DeliveryResponse> hold(String deliveryId, HoldDeliveryRequest holdDeliveryRequest) async
|
||||
test('test hold', () async {
|
||||
// TODO
|
||||
});
|
||||
|
||||
// Setzt die Lieferung zurück auf `active`. Nur aus `held` zulässig.
|
||||
//
|
||||
//Future<DeliveryResponse> resume(String deliveryId) async
|
||||
test('test resume', () async {
|
||||
// TODO
|
||||
});
|
||||
|
||||
});
|
||||
}
|
||||
Reference in New Issue
Block a user