Thiru-tenext
8207e27a97
Picks up where 0d66627 left off. Three things.
SIGN-IN, CUT TO THE QUESTION IT ASKS
It opened with a quarter-screen crimson hero carrying a lockup, a CUSTOMER
badge, a display-size promise and a sub-line, then a Phone/Email toggle, then a
labelled field, then a card explaining what a verification code is. Six things
to read before the one thing to do.
Nobody arrives at a sign-in screen needing to be sold the product. It is a
heading, a field and a button now, which is where Uber, Bolt and Porter put
them. The toggle became one quiet line under the field — choosing a method was
the first decision on the screen, before the customer had seen what was being
asked, and almost everyone uses the phone. The privacy card went: it explained
that a code would be sent, which the next screen demonstrates a second later.
`DmTextField.label` is nullable for this — "Enter your mobile number" above a
field captioned "Phone number" is one sentence printed twice.
BOOKING, DOWN TO ONE SCREENFUL
Landmark, recipient name and recipient phone are all optional and were all
drawn at the weight of the two fields that are not, putting six rows of "you
may skip this" between the address and the button. They fold behind one row
that counts what is filled in rather than just saying "optional".
Four crimson section heads became one. An accent used five times on a screen is
not an accent; crimson now marks the destination, which is the only choice that
changes the price.
Together those put the window, the package count and the CTA above the fold.
THE OFFLINE BUILD, BACK, UNDER TWO RULES
Deleted on 15 Sep after it cost two rounds of hunting for bookings in the admin
console that had never left the phone. That was not caused by the fake
existing — it was caused by a fake that did not announce itself and that
nothing stopped from shipping. Both are closed:
* `useDevData` is false in a release whatever the defines say;
* `describe` leads with DEV DATA (offline) and shows "no network" rather than
a host the build never contacts.
It is opt-in — `flutter run` still talks to the real API — which is the
property whose absence caused the original mess. `devAutoLogin` is deliberately
false under FLUTTER_TEST so the widget tests keep driving the real entrance.
flutter run --dart-define=DM_MOCK=true
86 tests green, analyze clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EqVJPB9B4QuieZnBAAKgYQ
93 lines
3.2 KiB
Dart
93 lines
3.2 KiB
Dart
import 'package:doormile_cx/data/dev_doormile_api.dart';
|
|
import 'package:doormile_cx/data/models.dart';
|
|
import 'package:doormile_cx/main.dart';
|
|
import 'package:doormile_cx/state/app_state.dart';
|
|
import 'package:flutter/material.dart';
|
|
import 'package:flutter_test/flutter_test.dart';
|
|
|
|
/// The login screen must not walk a customer to the code screen when no code
|
|
/// was sent.
|
|
///
|
|
/// `sent: false` is the server saying it accepted the request and delivered
|
|
/// nothing — the SMS gateway or the mail relay refused it. Advancing anyway
|
|
/// puts four empty boxes in front of someone for a code that does not exist,
|
|
/// and every digit they try is wrong. The failure then reads as "I typed it
|
|
/// wrong" instead of "nothing arrived", which is the wrong problem to hand
|
|
/// somebody.
|
|
///
|
|
/// The resend control on the code screen has always honoured this flag. The
|
|
/// login screen did not, which is the asymmetry these tests pin down.
|
|
|
|
/// The app runs continuous animations, so `pumpAndSettle` never returns.
|
|
Future<void> settle(WidgetTester tester, [int ms = 800]) async {
|
|
await tester.pump();
|
|
await tester.pump(Duration(milliseconds: ms));
|
|
await tester.pump(const Duration(milliseconds: 400));
|
|
}
|
|
|
|
class _SendFails extends DevDoormileApi {
|
|
@override
|
|
Future<OtpChallenge> sendOtp(String identifier) async =>
|
|
const OtpChallenge(sent: false);
|
|
}
|
|
|
|
class _SendSucceeds extends DevDoormileApi {
|
|
var calls = 0;
|
|
|
|
@override
|
|
Future<OtpChallenge> sendOtp(String identifier) async {
|
|
calls++;
|
|
return const OtpChallenge(sent: true);
|
|
}
|
|
}
|
|
|
|
Future<void> _tapContinue(WidgetTester tester, AppState state) async {
|
|
tester.view.physicalSize = const Size(1230, 9000);
|
|
tester.view.devicePixelRatio = 3.0;
|
|
addTearDown(tester.view.reset);
|
|
|
|
await tester.pumpWidget(DoormileApp(initialState: state));
|
|
await settle(tester);
|
|
|
|
await tester.enterText(find.byType(TextField).first, '9876543210');
|
|
await settle(tester, 200);
|
|
await tester.tap(find.text('Continue'));
|
|
await settle(tester);
|
|
}
|
|
|
|
void main() {
|
|
testWidgets('a code that was never sent does not open the code screen',
|
|
(tester) async {
|
|
await _tapContinue(tester, AppState(api: _SendFails()));
|
|
|
|
expect(
|
|
find.text('Verify your number'),
|
|
findsNothing,
|
|
reason: 'no code was delivered, so there is nothing to verify',
|
|
);
|
|
expect(
|
|
// The entry screen's heading. It used to be the promise on the crimson
|
|
// ("Book a pickup from your door."); the screen was cut back to an
|
|
// instruction, a field and a button, so the heading is now the
|
|
// instruction. What this asserts is unchanged: the customer is still on
|
|
// the sign-in screen and can try again.
|
|
find.text('Enter your mobile number'),
|
|
findsOneWidget,
|
|
reason: 'the customer stays where they can try again',
|
|
);
|
|
|
|
// Drain the toast timer so the test ends with nothing pending.
|
|
await tester.pump(const Duration(seconds: 4));
|
|
});
|
|
|
|
testWidgets('a delivered code does open the code screen', (tester) async {
|
|
final api = _SendSucceeds();
|
|
await _tapContinue(tester, AppState(api: api));
|
|
|
|
expect(find.text('Verify your number'), findsOneWidget);
|
|
expect(api.calls, 1);
|
|
|
|
await tester.pump(const Duration(seconds: 4));
|
|
});
|
|
}
|