@sungen/driver-ui 3.2.34-beta.1 → 3.2.35

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sungen/driver-ui",
-  "version": "3.2.34-beta.1",
+  "version": "3.2.35",
   "description": "Sungen UI capability (Playwright) — step patterns, viewpoint gate, and phase hooks. Plugs into @sun-asterisk/sungen via the capability SPI.",
   "main": "src/index.ts",
   "types": "src/index.ts",
@@ -13,7 +13,7 @@
   "author": "eqe team (engineer & quality) — Sun Asterisk",
   "license": "MIT",
   "dependencies": {
-    "@sun-asterisk/sungen": "3.2.34-beta.1"
+    "@sun-asterisk/sungen": "3.2.35"
   },
   "peerDependencies": {
     "@playwright/test": "^1.57.0"

package/src/patterns/assertion-patterns.ts

@@ -1,9 +1,10 @@
 import { ParsedStep } from '@sun-asterisk/sungen';
 import { formatToRegexLiteral } from '@sun-asterisk/sungen';
-import { StepPattern, StepTemplateData, expandRecipe } from '@sun-asterisk/sungen';
+import { StepPattern, StepTemplateData, PatternContext, MappedStep, expandRecipe, unsupportedStepCode } from '@sun-asterisk/sungen';
 import { LIST_MEMBER_ROLES } from '@sun-asterisk/sungen';
 import { urlToPatternParts } from '../utils/url-path-regex';
 import { resolveColumnHeaderName } from '../utils/column-header';
+import { isDatePickerType } from './form-patterns';
 
 /**
  * Assertion patterns: visibility, text content, state, attributes
@@ -44,6 +45,37 @@ const IDENTITY_STRATEGIES = new Set([
   'accessibility-id', 'android-uiautomator', 'ios-predicate',
 ]);
 
+const EXPANDED_STATE_ALTERNATIVE =
+  'a native app exposes no expanded state - assert what the open panel shows instead (e.g. `see [X] section`)';
+
+/**
+ * `see [X] … is expanded | is collapsed` — the assertion twin of the expand/collapse actions. Before
+ * `expanded`/`collapsed` were state clauses the sentence fell to should-be-visible and the state
+ * vanished: the step passed with the calendar closed (#911). Reads the SAME signal the action drives
+ * (`expanded: { class | attribute }`, else aria-expanded), but strictly — the action's "assert only if
+ * the attribute exists" leniency would make this assert nothing. A generator, not a resolver, because
+ * `expanded: { state: none }` must refuse with a diagnostic rather than render a template.
+ */
+function expandedStateAssertion(step: ParsedStep, context: PatternContext, state: 'expanded' | 'collapsed'): MappedStep {
+  const resolved = context.selectorResolver.resolveSelector(step.selectorRef!, undefined, step.elementType, step.nth);
+  // `state: none` is the author saying the widget shows no open/closed state, so there is nothing
+  // honest to assert — refuse rather than fall back to aria-expanded.
+  if (resolved.expanded?.state) {
+    const reason =
+      `step "${step.text}" asserts [${step.selectorRef}] is ${state}, but that entry declares `
+      + `expanded.state: ${resolved.expanded.state} (no observable state). Declare expanded.class or `
+      + `expanded.attribute on the entry, or assert what the open panel shows instead.`;
+    context.diagnostics?.add('SG-W017', reason, { feature: context.featureName, step: step.text });
+    return { code: unsupportedStepCode(reason), comment: `${step.selectorRef} has no ${state} state — see SG-W017` };
+  }
+  return {
+    code: context.templateEngine.renderStep('expanded-assertion', {
+      ...resolved, selectorRef: step.selectorRef, direction: state === 'expanded' ? 'expand' : 'collapse',
+    }),
+    comment: `Assert ${step.selectorRef} is ${state}`,
+  };
+}
+
 /**
  * INVARIANT — a pattern whose generated code accounts for a trailing state clause (`… is hidden`)
  * MUST declare it in `states`. Undeclared, the clause reaches SG-E021 and the step compiles to a
@@ -397,6 +429,7 @@ export const assertionPatterns: StepPattern[] = [
       ]);
       // Subset of INPUT_TYPES whose DOM implementation cannot be inferred from the token:
       // a component library may render any of these as a non-input trigger element.
+      // (A date-picker is handled alongside, as `isDatePicker` below, #907.)
       const AMBIGUOUS_VALUE_TYPES = new Set(['dropdown', 'select', 'combobox']);
 
       // Resolve data variable value
@@ -441,11 +474,24 @@ export const assertionPatterns: StepPattern[] = [
           (AMBIGUOUS_VALUE_TYPES.has(step.elementType) ||
             ['combobox', 'listbox'].includes(resolved.role)) &&
           resolved.variant !== 'native';
+        // A date-picker is just as ambiguous: its trigger is often a <button> opening a calendar
+        // popup, which has no `value` and shows the chosen date as text (#907).
+        const isDatePicker = isDatePickerType(step.elementType) && resolved.variant !== 'native';
 
-        if (ambiguous) {
-          // `assertValue` is the third recipe intent the app-profile spec defines alongside
-          // `fill`/`select` (spec §3.1). Same lookup shape as the select-dropdown fork.
-          const variantName = resolved.variant || context.appProfile?.widgetVariants?.['select'];
+        // `assertValue` is the third recipe intent the app-profile spec defines alongside
+        // `fill`/`select` (spec §3.1). The lookup mirrors the fill step: a per-element `variant:`
+        // wins for ANY element type, then the profile's widget default for the type. It used to be
+        // consulted for dropdowns only, so a date-picker whose `fill` ran its recipe still asserted
+        // with toHaveValue() on the button (#907).
+        // Web only: the appium adapter ships no recipe-sequence and reads native values instead.
+        if (context.platform !== 'mobile') {
+          // A date-picker reads `widgets.datepicker` first — exactly as its fill does — even when it
+          // wears `role: combobox` (the shadcn/Radix trigger), which also makes it `ambiguous`.
+          const variantName =
+            resolved.variant ||
+            (isDatePicker ? context.appProfile?.widgetVariants?.['datepicker']
+              : ambiguous ? context.appProfile?.widgetVariants?.['select']
+              : undefined);
           const recipeSteps =
             variantName && variantName !== 'native'
               ? context.appProfile?.recipes?.[variantName]?.['assertValue']
@@ -469,7 +515,7 @@ export const assertionPatterns: StepPattern[] = [
         const code = context.templateEngine.renderStep('have-value-assertion', {
           ...resolved,
           dataValue,
-          probeNative: ambiguous,
+          probeNative: ambiguous || isDatePicker,
         });
         return {
           code,
@@ -495,17 +541,27 @@ export const assertionPatterns: StepPattern[] = [
         // CONTAINS, not exact: an entry for a label/value pair points legitimately either at
         // the value node ("JD-001") or at the row holding both ("Job No: JD-001"), and the web
         // regex it replaces was itself anchored only at the end. `exact: true` opts into the
-        // strict comparison.
+        // strict comparison. An EMPTY expected value is strict too: `toContainText('')` passes on
+        // any text at all, so "the field is blank" would assert nothing (#910). Judged on the base
+        // test-data value — the same compile-time read SG-W015 uses. An env overlay can change the
+        // value at run time; a base '' with a non-empty overlay then compares exactly.
         //
         // `resolved` is the SAME lookup, already performed above — this branch used to repeat it.
         if (IDENTITY_STRATEGIES.has(resolved.strategy)) {
+          // Empty on every value the ref takes (each @cases row, #950) → strict.
+          const values = context.dataResolver.peekValues
+            ? context.dataResolver.peekValues(step.dataRef, context.featureName)
+            : [context.dataResolver.peekBaseValue?.(step.dataRef, context.featureName)].filter((v): v is string => v !== undefined);
+          const strict = resolved.exact || (!!values?.length && values.every((v) => v === ''));
           const code = context.templateEngine.renderStep(
-            resolved.exact ? 'have-text-assertion' : 'contain-text-assertion',
-            { ...resolved, expectedText: dataValue },
+            strict ? 'have-text-assertion' : 'contain-text-assertion',
+            // `strict` reads the BASE value at compile time; the runtime guard also covers an env
+            // overlay that sets '' over a non-empty base (#910).
+            { ...resolved, expectedText: dataValue, emptyMeansEmpty: true },
           );
           return {
             code,
-            comment: `Assert ${step.selectorRef} label ${resolved.exact ? 'has' : 'contains'} value ${step.dataRef}`,
+            comment: `Assert ${step.selectorRef} label ${strict ? 'has' : 'contains'} value ${step.dataRef}`,
           };
         }
 
@@ -827,6 +883,28 @@ export const assertionPatterns: StepPattern[] = [
     },
     priority: 11,
   },
+  {
+    name: 'is-expanded',
+    states: ['expanded'],
+    platforms: ['web'],
+    platformAlternative: EXPANDED_STATE_ALTERNATIVE,
+    // A word match like the sibling state patterns (`is-disabled`), not `step.state`: that one is set
+    // only for a TRAILING clause, so `… is expanded  # calendar open` fell back to toBeVisible().
+    matcher: (step: ParsedStep) =>
+      /\b(see|sees)\s+\[/.test(step.text) && /\bis expanded\b/.test(step.text) && !step.dataRef && !!step.selectorRef,
+    generator: (step, context) => expandedStateAssertion(step, context, 'expanded'),
+    priority: 11,
+  },
+  {
+    name: 'is-collapsed',
+    states: ['collapsed'],
+    platforms: ['web'],
+    platformAlternative: EXPANDED_STATE_ALTERNATIVE,
+    matcher: (step: ParsedStep) =>
+      /\b(see|sees)\s+\[/.test(step.text) && /\bis collapsed\b/.test(step.text) && !step.dataRef && !!step.selectorRef,
+    generator: (step, context) => expandedStateAssertion(step, context, 'collapsed'),
+    priority: 11,
+  },
   {
     name: 'is-focused',
     states: ['focused'],

package/src/patterns/form-patterns.ts

@@ -1,6 +1,25 @@
 import { ParsedStep } from '@sun-asterisk/sungen';
 import { StepPattern, StepTemplateData, expandRecipe } from '@sun-asterisk/sungen';
 
+/** A date-picker / calendar element type — the steps that read `widgets.datepicker` agree on it. */
+export const isDatePickerType = (elementType: string | undefined): boolean =>
+  /date-?picker|calendar/.test(String(elementType || ''));
+
+/**
+ * Whether an entry provably locates a `<button>`: a `button` role, or a CSS/locator selector whose
+ * LAST compound starts with the `button` tag (`div.filters button[aria-haspopup="dialog"]`).
+ * Attribute brackets are dropped first so a `[name="button"]` value cannot read as the tag. A
+ * selector LIST (`input.date, button.trigger`) may match the input, so it is never called a button.
+ */
+function isButtonTrigger(resolved: { strategy?: string; role?: string; value?: string }): boolean {
+  if (resolved.strategy === 'role') return resolved.role === 'button';
+  if (resolved.strategy !== 'css' && resolved.strategy !== 'locator') return false;
+  const selector = String(resolved.value ?? '').replace(/\[[^\]]*\]/g, '').trim();
+  if (selector.includes(',')) return false;
+  const compounds = selector.split(/[\s>+~]+/);
+  return /^button(?![\w-])/i.test(compounds[compounds.length - 1] ?? '');
+}
+
 /**
  * Form action patterns: fill, type, select, check, uncheck
  */
@@ -50,7 +69,7 @@ export const formPatterns: StepPattern[] = [
       // Widget recipe hook: per-element `variant:` wins; else, for a date-picker element,
       // the profile's `widgets.datepicker` (custom datepickers — readonly inputs that need
       // open-panel choreography). Resolves to a recipe with a `fill` intent.
-      const isDatePicker = /date-?picker|calendar/.test(String(step.elementType || ''));
+      const isDatePicker = isDatePickerType(step.elementType);
       const fillVariant = resolved.variant || (isDatePicker ? context.appProfile?.widgetVariants?.['datepicker'] : undefined);
       const fillRecipe = fillVariant ? context.appProfile?.recipes?.[fillVariant]?.['fill'] : undefined;
       if (fillRecipe) {
@@ -92,6 +111,25 @@ export const formPatterns: StepPattern[] = [
         };
       }
 
+      // A web date-picker whose trigger is a BUTTON, with no recipe: `.fill()` throws "Element is
+      // not an <input>" on it, and there is no value to type — the date is chosen in the calendar
+      // the button opens. Refuse at compile time and name the recipe to declare (#907). Only the
+      // shapes that are provably a button are refused; any other locator may still be a native
+      // `<input type="date">`, where the generic fill is right.
+      if (isDatePicker && isButtonTrigger(resolved)) {
+        const reason =
+          `step "${step.text}" fills [${step.selectorRef}] date-picker, but that entry locates a button `
+          + `(a calendar trigger) and no recipe drives it — fill() cannot type into a button. Declare a `
+          + `recipe with a fill intent in qa/app.yaml and point the entry at it with variant: <recipe> `
+          + `(or set widgets.datepicker), or tag this scenario @manual.`;
+        context.diagnostics?.add('SG-W017', reason, { feature: context.featureName, step: step.text });
+        return {
+          templateName: 'date-picker-unsupported',
+          data: { reason },
+          comment: `date-picker trigger is a button with no fill recipe — see SG-W017`,
+        };
+      }
+
       // Rich-text editors fill with pressSequentially, not .fill(). Two ways in: the selector
       // entry (`contenteditable: true`, which the resolver translates into `inputMethod`, #712 —
       // or `inputMethod` written out), and the Gherkin `editor` element type, which is a property
@@ -104,9 +142,16 @@ export const formPatterns: StepPattern[] = [
       const isEditor = resolved.inputMethod === 'pressSequentially' || step.elementType === 'editor';
       const templateName = isEditor ? 'fill-editor-action' : 'fill-action';
 
+      // `.fill()` only works on an input / textarea / select / contenteditable. A date-picker whose
+      // trigger is a <button> opening a calendar popup (Radix Popover + React Day Picker), or an
+      // entry that is plainly a button or link, fails with Playwright's "Element is not an <input>"
+      // — which says nothing about the fix. Guard those at runtime with the way forward: a recipe
+      // with a `fill` intent (#907). A locator's tag is unknown at compile time, hence a probe.
+      const guardFillable = !isEditor && (isDatePicker || ['button', 'link'].includes(String(resolved.role || '')));
+
       return {
         templateName,
-        data: { ...resolved, selectorRef: step.selectorRef, fillValue: value },
+        data: { ...resolved, selectorRef: step.selectorRef, fillValue: value, ...(guardFillable ? { guardFillable: true } : {}) },
         comment: isEditor
           ? `Fill rich text editor ${step.selectorRef} with ${step.dataRef || step.value}`
           : `Fill ${step.selectorRef} with ${step.dataRef || step.value}`,

package/src/patterns/table-patterns.ts

@@ -234,9 +234,21 @@ export const tablePatterns: StepPattern[] = [
              !/\bis\s+hidden\b/i.test(step.text);
     },
     resolver: (step, context) => {
-      // Decide by the BASE literal (runtime mode returns an opaque marker from resolveData).
-      const base = context.dataResolver.peekBaseValue?.(step.dataRef!, context.featureName);
-      if (base === undefined || !/^\d+$/.test(String(base).trim())) return null as any; // not numeric → fall through to text semantics
+      // Decide by the literal value(s) (runtime mode returns an opaque marker from resolveData). In
+      // @cases a dataset column has one value per row: it is a count only when EVERY row is a
+      // number (#950). Mixed rows compile to text — and say so, since some rows read as counts.
+      const values = context.dataResolver.peekValues
+        ? context.dataResolver.peekValues(step.dataRef!, context.featureName)
+        : [context.dataResolver.peekBaseValue?.(step.dataRef!, context.featureName)].filter((v): v is string => v !== undefined);
+      const isCount = (v: string) => /^\d+$/.test(v.trim());
+      if (!values?.length || !values.every(isCount)) {
+        if (values?.some(isCount)) {
+          context.diagnostics?.add('SG-W015',
+            `\`see [${step.selectorRef}] row with {{${step.dataRef}}}\` mixes numbers and text across the @cases rows, so it compiles to a TEXT assertion, not a row count. Split the counting rows into their own @cases scenario.`,
+            { feature: context.featureName, step: step.text });
+        }
+        return null as any; // not numeric → fall through to text semantics
+      }
       const resolved = context.selectorResolver.resolveSelector(
         step.selectorRef!, context.featureName, 'row', step.nth
       );