Both READMEs claimed web parity with data export/import as the only
omission. That was three gaps out of date: the car screen had no
connected-service tab, no per-car charging-cost tab, and no way to say what
a car's page shows - all three of which the web has had since the car view
became a property of the car rather than of the browser.
The tab bar was the thing blocking the rest. It was a fixed list of eight
Tab(text: "Information") literals, so it could neither grow a tab nor read
an arrangement, and it sat outside the translation system that the rest of
the app has used since b6bb6b1. It now builds from the car's own tabOrder
and hiddenTabs, and labels come from car.tabs.* like the web's.
Rather than retype four subtrees of strings in three languages, the shared
ones - car.*, settings.advanced, forms.charging, forms.import and the
common keys the phone was missing - are copied out of the Web App's own
language files, with the phone's existing wording winning every collision.
Polish and Danish therefore arrive complete and cannot drift between the
two apps. Only five strings are genuinely phone-only: the reorder hint, the
saved-file message, the open action and two validation lines.
The connected-service tab mirrors ProviderPanel: headline readings, the
offer to take a provider odometer that is ahead of the stored one, the
vehicle record, and one collapsible card per capability, rendered from the
server's flattened key/value pairs so a provider adding a field surfaces it
without touching this app. Two deliberate differences. The raw-payload
disclosure is dropped - Toyota's eight sections are megabytes of JSON on a
phone screen, and the flattened fields carry the same content. And the
readings cannot be dragged here, though a stored metricOrder is still
honoured, so an arrangement made on the web carries over.
The view picker takes the same line on gestures. The web rearranges by
dragging the tab bar itself and the Information rows themselves; on a touch
screen that gesture belongs to the tab bar, so both arrangements are made
in the picker with a handle instead, and hiddenTabs, hiddenFields, tabOrder
and fieldOrder all save in one PUT. The key catalogues live in
car_view_sheet.dart and mirror hideableCarTabs / arrangeableCarTabs /
hideableCarFields in cars.go, because the server rejects anything else.
arrangeKeys applies a partial stored order the way the API documents it: an
unknown key is dropped and an unnamed one follows the arranged ones, which
is what puts a tab added in a later release at the end of somebody's page
rather than the middle of it.
Charging cost is the electric twin of Fuel and is built as one - the same
stats panel, tile and form shape, measured between full charges. It is the
per-car cost log, not the Charging section in the bottom bar, which remains
the charger network and OCPP control.
Export and import needed a phone answer to two browser affordances. The
export is written to the app's documents directory under the filename the
server's Content-Disposition names, and offered to whatever opens JSON via
open_filex - the same route attachments already take. The import goes
through the system file picker, validates the file locally, and confirms
with the number of cars the file actually holds, because the server always
creates new records and never merges.
The one field worth calling out on the client: _carPayload still leaves the
provider link and the view arrangement out, matching carPayload in
records.go, so saving the car form cannot silently unlink a car or undo an
arrangement.
Known gap, deliberately not closed here: the older sheets in
record_form_sheets.dart and most of car_detail_screen.dart still carry
hardcoded English. Everything added here and every tab label goes through
t(), but translating the rest of the car screen is its own change and would
have buried this one.
Verified by flutter analyze (clean), flutter test - 13 pass, 6 of them new,
covering arrangeKeys against partial, unknown and duplicate keys, the
charging models keeping uncomputed figures null rather than a plausible
zero, the new Car fields, and ProviderSnapshot parsing an unreachable
provider as an answer rather than a failure - and flutter build apk
--debug, which succeeds. The Kotlin Gradle plugin warnings in that build
are pre-existing.
Not verified: nothing was run against a live API Server or on a device, so
the new screens have not been driven end to end - only compiled, analyzed
and unit-tested.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
295 lines
11 KiB
Dart
295 lines
11 KiB
Dart
// Parses server-shaped JSON through the models and checks the status/format
|
|
// helpers.
|
|
//
|
|
// These cover the parts where a mistake is invisible until it reaches a user: a
|
|
// derived field the server left out must stay null rather than becoming a
|
|
// plausible-looking zero, the badge wording has to match the web app's, and an
|
|
// unsupported locale (settable from the web, whose lists are wider than the
|
|
// phone's) must not throw out of every date on screen.
|
|
import "package:flutter_test/flutter_test.dart";
|
|
import "package:intl/date_symbol_data_local.dart";
|
|
import "package:drivervault_phone/format.dart";
|
|
import "package:drivervault_phone/i18n.dart";
|
|
import "package:drivervault_phone/main.dart";
|
|
import "package:drivervault_phone/models.dart";
|
|
import "package:drivervault_phone/screens/car_view_sheet.dart";
|
|
|
|
void main() {
|
|
// rootBundle (used by loadTranslations) needs the binding initialised.
|
|
TestWidgetsFlutterBinding.ensureInitialized();
|
|
|
|
setUpAll(() async {
|
|
await initializeDateFormatting();
|
|
await loadTranslations();
|
|
// Polish exercises both the region-aware number grouping and the localized
|
|
// status wording (one/few/many plurals), so the badge labels below are the
|
|
// Polish strings — the same text the web app renders under pl.
|
|
appSettings.locale = "pl-PL";
|
|
appSettings.currency = "PLN";
|
|
appSettings.dateFormat = "DMY";
|
|
});
|
|
|
|
test("FuelEntry keeps uncomputed derived fields null, not zero", () {
|
|
final partial = FuelEntry.fromJson({
|
|
"id": "a",
|
|
"car": "c",
|
|
"date": "2026-07-01T00:00:00Z",
|
|
"km": 1000,
|
|
"liters": 20.0,
|
|
"cost": 120.0,
|
|
"fullTank": false,
|
|
"hasFile": false,
|
|
});
|
|
expect(partial.consumptionL100, isNull);
|
|
expect(partial.distanceKm, isNull);
|
|
expect(formatConsumption(partial.consumptionL100), "—");
|
|
|
|
final full = FuelEntry.fromJson({
|
|
"id": "b",
|
|
"car": "c",
|
|
"date": "2026-07-10T00:00:00Z",
|
|
"km": 1500,
|
|
"liters": 35.0,
|
|
"cost": 210.0,
|
|
"fullTank": true,
|
|
"consumptionL100": 6.85,
|
|
"distanceKm": 500,
|
|
"kmPerLiter": 14.6,
|
|
"pricePerLiter": 6.0,
|
|
"fileName": "receipt.pdf",
|
|
"hasFile": true,
|
|
});
|
|
expect(full.consumptionL100, 6.85);
|
|
// 6.85 as a float64 is really 6.8499…, so one-decimal rounding yields 6.8 —
|
|
// the same answer JS toFixed(1) gives the web app.
|
|
expect(formatConsumption(full.consumptionL100), "6.8 L/100km");
|
|
expect(full.hasFile, isTrue);
|
|
expect(full.fileName, "receipt.pdf");
|
|
});
|
|
|
|
test("expiryStatus wording follows the server assessment", () {
|
|
CarDocument doc(String state, int? days) => CarDocument.fromJson({
|
|
"id": "d",
|
|
"car": "c",
|
|
"type": "insurance",
|
|
"title": "OC",
|
|
"expiry": {"state": state, "daysUntilExpiry": days},
|
|
"hasFile": false,
|
|
});
|
|
expect(expiryStatus(doc("expired", -5).expiry).label, "Wygasło 5 dni temu");
|
|
expect(expiryStatus(doc("expiring_soon", 0).expiry).label, "Wygasa dzisiaj");
|
|
expect(expiryStatus(doc("expiring_soon", 12).expiry).label, "Odnowienie za 12 dni");
|
|
expect(expiryStatus(doc("valid", 200).expiry).label, "Ważne · 200 dni");
|
|
expect(expiryStatus(doc("no_expiry", null).expiry).label, "Bezterminowe");
|
|
expect(expiryStatus(doc("expired", -5).expiry).key, StatusKey.overdue);
|
|
});
|
|
|
|
test("reminderStatus leads with the driving trigger", () {
|
|
Reminder rem(Map<String, dynamic> extra) =>
|
|
Reminder.fromJson({"id": "r", "car": "c", "title": "t", "type": "service", ...extra});
|
|
|
|
expect(reminderStatus(rem({"status": "done", "done": true})).label, "Gotowe");
|
|
expect(reminderStatus(rem({"status": "no_trigger"})).label, "Brak wyzwalacza");
|
|
expect(
|
|
reminderStatus(rem({"status": "overdue", "daysLeft": -3, "kmLeft": -200})).label,
|
|
"Zaległe 3 dni · 200 km");
|
|
expect(reminderStatus(rem({"status": "due_soon", "daysLeft": 0})).label, "Termin za dzisiaj");
|
|
// The km count is grouped per the chosen locale (pl-PL groups thousands with
|
|
// a space), which is the whole point of routing every number through the one
|
|
// helper. Asserted as start + end so the exact space glyph (ICU uses a
|
|
// non-breaking space) does not make the test brittle.
|
|
final due = reminderStatus(rem({"status": "upcoming", "daysLeft": 40, "kmLeft": 5000})).label;
|
|
expect(due, startsWith("Termin za 40 dni · 5"));
|
|
expect(due, endsWith("000 km"));
|
|
});
|
|
|
|
test("TechnicalCheck: a failed check derives no next date", () {
|
|
final failed = TechnicalCheck.fromJson({
|
|
"id": "t",
|
|
"car": "c",
|
|
"date": "2026-07-01T00:00:00Z",
|
|
"result": "failed",
|
|
"cost": 99.0,
|
|
"expiry": {"state": "no_expiry", "daysUntilExpiry": null},
|
|
"hasFile": false,
|
|
});
|
|
expect(failed.nextCheckDate, isNull);
|
|
expect(failed.passed, isFalse);
|
|
});
|
|
|
|
test("Maintenance derived warranty + total", () {
|
|
final m = MaintenanceEntry.fromJson({
|
|
"id": "m",
|
|
"car": "c",
|
|
"date": "2026-07-01T00:00:00Z",
|
|
"km": 1000,
|
|
"type": "repair",
|
|
"status": "completed",
|
|
"laborCost": 100.0,
|
|
"partsCost": 50.0,
|
|
"totalCost": 150.0,
|
|
"warrantyActive": true,
|
|
"warrantyDaysLeft": 10,
|
|
"hasFile": false,
|
|
});
|
|
expect(m.totalCost, 150.0);
|
|
expect(warrantyStatus(m)!.label, "Gwarancja kończy się za 10 dni");
|
|
expect(warrantyStatus(m)!.key, StatusKey.soon);
|
|
|
|
final noWarranty = MaintenanceEntry.fromJson(
|
|
{"id": "m", "car": "c", "date": "2026-07-01T00:00:00Z", "hasFile": false});
|
|
expect(warrantyStatus(noWarranty), isNull);
|
|
});
|
|
|
|
test("money and numbers follow the chosen locale/currency", () {
|
|
expect(formatMoney(1234.5).contains("zł"), isTrue);
|
|
expect(formatMoney(null), "—");
|
|
// An unsupported language must not throw — it can be set from the web.
|
|
appSettings.locale = "rm-CH";
|
|
expect(() => formatDate(DateTime(2026, 7, 17)), returnsNormally);
|
|
expect(() => formatMoney(10), returnsNormally);
|
|
expect(() => formatKm(15000), returnsNormally);
|
|
appSettings.locale = "pl-PL";
|
|
});
|
|
|
|
test("Car carries the technical check interval", () {
|
|
final car = Car.fromJson({"id": "c", "name": "Yaris", "technicalCheckIntervalDays": 730});
|
|
expect(car.technicalCheckIntervalDays, 730);
|
|
});
|
|
|
|
test("ChargingSession keeps uncomputed derived fields null, not zero", () {
|
|
final partial = ChargingSession.fromJson({
|
|
"id": "a",
|
|
"car": "c",
|
|
"date": "2026-07-01T00:00:00Z",
|
|
"km": 1000,
|
|
"kwh": 22.5,
|
|
"cost": 30.0,
|
|
"fullCharge": false,
|
|
"hasFile": false,
|
|
});
|
|
expect(partial.consumptionKwh100, isNull);
|
|
expect(partial.distanceKm, isNull);
|
|
expect(formatKwhConsumption(partial.consumptionKwh100), "—");
|
|
expect(formatKmPerKwh(partial.kmPerKwh), "—");
|
|
expect(formatKwh(partial.kwh), "22.50 kWh");
|
|
|
|
final closed = ChargingSession.fromJson({
|
|
"id": "b",
|
|
"car": "c",
|
|
"date": "2026-07-20T00:00:00Z",
|
|
"km": 1400,
|
|
"kwh": 60.0,
|
|
"cost": 90.0,
|
|
"fullCharge": true,
|
|
"pricePerKwh": 1.5,
|
|
"distanceKm": 400,
|
|
"consumptionKwh100": 15.0,
|
|
"kmPerKwh": 6.67,
|
|
});
|
|
expect(closed.consumptionKwh100, 15.0);
|
|
expect(formatKwhConsumption(closed.consumptionKwh100), "15.0 kWh/100km");
|
|
});
|
|
|
|
test("ChargingStats leaves averages null when nothing is computable", () {
|
|
final stats = ChargingStats.fromJson({
|
|
"entries": 1,
|
|
"totalKwh": 22.5,
|
|
"totalCost": 30.0,
|
|
"trackedDistanceKm": 0,
|
|
});
|
|
expect(stats.entries, 1);
|
|
expect(stats.avgConsumptionKwh100, isNull);
|
|
expect(formatKwhConsumption(stats.avgConsumptionKwh100), "—");
|
|
});
|
|
|
|
test("Car carries the provider link and the view arrangement", () {
|
|
final car = Car.fromJson({
|
|
"id": "c",
|
|
"name": "bZ4X",
|
|
"provider": "toyota",
|
|
"providerVehicleId": "VIN123",
|
|
"hiddenTabs": ["fuel"],
|
|
"hiddenFields": ["differentialOil"],
|
|
"tabOrder": ["info", "charging"],
|
|
"fieldOrder": ["vin"],
|
|
"metricOrder": ["evRange", "odometer"],
|
|
});
|
|
expect(car.provider, "toyota");
|
|
expect(car.providerVehicleId, "VIN123");
|
|
expect(car.hiddenTabs, ["fuel"]);
|
|
expect(car.tabOrder, ["info", "charging"]);
|
|
expect(car.metricOrder, ["evRange", "odometer"]);
|
|
|
|
// A car nobody has arranged carries empty lists, not nulls — the callers
|
|
// read them directly.
|
|
final plain = Car.fromJson({"id": "d", "name": "Yaris"});
|
|
expect(plain.provider, "");
|
|
expect(plain.hiddenTabs, isEmpty);
|
|
expect(plain.tabOrder, isEmpty);
|
|
});
|
|
|
|
test("arrangeKeys: partial orders keep every key, unknown ones are dropped", () {
|
|
// The keys the stored order names lead; the rest follow in catalogue order,
|
|
// which is what puts a tab added in a later release at the end of somebody's
|
|
// page rather than in the middle of it.
|
|
expect(
|
|
arrangeKeys(kCarTabKeys, ["charging", "info"]).take(2).toList(),
|
|
["charging", "info"],
|
|
);
|
|
expect(arrangeKeys(kCarTabKeys, ["charging", "info"]).length, kCarTabKeys.length);
|
|
expect(arrangeKeys(kCarTabKeys, ["charging", "info"]).toSet(), kCarTabKeys.toSet());
|
|
|
|
// A key from a newer release, and a duplicate, are both ignored.
|
|
final arranged = arrangeKeys(kCarTabKeys, ["tyres", "vin", "fuel", "fuel"]);
|
|
expect(arranged.first, "fuel");
|
|
expect(arranged.length, kCarTabKeys.length);
|
|
|
|
// No arrangement at all means the catalogue's own order.
|
|
expect(arrangeKeys(kCarInfoFieldKeys, const []), kCarInfoFieldKeys);
|
|
});
|
|
|
|
test("ProviderSnapshot: an unreachable provider parses as an answer, not a failure", () {
|
|
final closed = ProviderSnapshot.fromJson({
|
|
"provider": "toyota",
|
|
"label": "MyToyota",
|
|
"unavailable": true,
|
|
"detail": "this vehicle is not on your MyToyota account",
|
|
});
|
|
expect(closed.unavailable, isTrue);
|
|
expect(closed.vehicle, isNull);
|
|
expect(closed.metrics, isEmpty);
|
|
expect(closed.detail, contains("MyToyota"));
|
|
|
|
final open = ProviderSnapshot.fromJson({
|
|
"provider": "toyota",
|
|
"label": "MyToyota",
|
|
"fetchedAt": "2026-08-21T09:30:00Z",
|
|
"vehicle": {"id": "VIN123", "vin": "VIN123", "name": "bZ4X", "make": "Toyota", "year": 2024},
|
|
"metrics": [
|
|
{"key": "odometer", "value": "16138", "unit": "km"},
|
|
{"key": "batteryLevel", "value": "72", "unit": "%"},
|
|
],
|
|
"sections": [
|
|
{"id": "telemetry", "status": "ok", "fields": [{"key": "a.b", "value": "1"}]},
|
|
{"id": "notifications", "status": "error", "error": "upstream said no"},
|
|
],
|
|
"suggestedCurrentKm": 16138,
|
|
});
|
|
expect(open.vehicle!.subtitle, "Toyota 2024");
|
|
expect(open.metrics.first.key, "odometer");
|
|
expect(open.sections.last.status, "error");
|
|
expect(open.sections.first.fields.single.key, "a.b");
|
|
expect(open.suggestedCurrentKm, 16138);
|
|
expect(open.fetchedAt, isNotNull);
|
|
});
|
|
|
|
test("ImportResult reads the server's per-collection counts", () {
|
|
final res = ImportResult.fromJson(
|
|
{"carsImported": 2, "servicesImported": 11, "partsImported": 4});
|
|
expect(res.cars, 2);
|
|
expect(res.services, 11);
|
|
expect(res.parts, 4);
|
|
});
|
|
}
|