test(editor): assert the derived block marker, not a column name #377

Merged
allan merged 1 commits from fix/derived-block-spec into release/7.19 2026-10-27 22:25:31 +00:00
Collaborator

Build-and-test-development has been red on one Cypress assertion, and the assertion was wrong, not the client.

✖ derived-variables.cy.ts   5 tests, 4 passing, 1 failing
  4 | a derived column is marked read-only, and opens no editor
  AssertionError: expected '<th.dc-derived-header.darkTH>' to have class 'dc-derived-first'

What the grid actually does

Reproduced locally against a mock sasjs/server in desktop mode (RUN_TIMES=js, ng serve on :4200) and dumped the header row:

0 |  | darkTH
1 | Delete? | firstColumnHeaderStyle darkTH
2 | ID | primaryKeyHeaderStyle darkTH
3 | STATE | darkTH
4 | QTY | darkTH
5 | PRICE | darkTH
6 | LINE_VALUE | dc-derived-header dc-derived-first darkTH
7 | REGION | dc-derived-header darkTH
8 | REGION_LABEL | dc-derived-header beforeHiddenColumn htLastVisibleHeader

The marker is on LINE_VALUE, and that is right: the derived columns appear in MPE_DERIVED order, which for TESTDATA.DERIVED_DEMO is LINE_VALUE, REGION, REGION_LABEL. The spec's comment said "REGION is the first derived column, so it opens the computed block", and line 97 asserted that name.

The same dump against the unmodified release/7.19 client gives byte-identical output, so no client change was needed for this.

Change

The assertion now states the invariant instead of a column name:

cy.get('.ht_clone_top .htCore thead tr th').then(($ths) => {
  const derived = [...$ths].filter((th) => th.classList.contains('dc-derived-header'))
  expect(derived.length, 'derived headers').to.be.greaterThan(0)
  expect(derived[0].classList.contains('dc-derived-first'),
    'the first derived header opens the block').to.be.true
  derived.slice(1).forEach((th) =>
    expect(th.classList.contains('dc-derived-first'),
      'only the first derived header carries the marker').to.be.false)
})

It still fails if the marker is missing, if it lands on the wrong column, or if more than one column carries it - but it no longer depends on which variable the control table lists first.

Verification

Running:  derived-variables.cy.ts
5 passing (1m)
✔  All specs passed!   5  5  -  -  -

Local mock estate: sasjs/server desktop mode, JS runtime, mocks deployed with sasjs cbd -t server-ci, app served by ng serve - the same shape as the pipeline step. No SAS changes.

`Build-and-test-development` has been red on one Cypress assertion, and the assertion was wrong, not the client. ``` ✖ derived-variables.cy.ts 5 tests, 4 passing, 1 failing 4 | a derived column is marked read-only, and opens no editor AssertionError: expected '<th.dc-derived-header.darkTH>' to have class 'dc-derived-first' ``` ## What the grid actually does Reproduced locally against a mock `sasjs/server` in desktop mode (`RUN_TIMES=js`, `ng serve` on :4200) and dumped the header row: ``` 0 | | darkTH 1 | Delete? | firstColumnHeaderStyle darkTH 2 | ID | primaryKeyHeaderStyle darkTH 3 | STATE | darkTH 4 | QTY | darkTH 5 | PRICE | darkTH 6 | LINE_VALUE | dc-derived-header dc-derived-first darkTH 7 | REGION | dc-derived-header darkTH 8 | REGION_LABEL | dc-derived-header beforeHiddenColumn htLastVisibleHeader ``` The marker is on **LINE_VALUE**, and that is right: the derived columns appear in MPE_DERIVED order, which for `TESTDATA.DERIVED_DEMO` is LINE_VALUE, REGION, REGION_LABEL. The spec's comment said "REGION is the first derived column, so it opens the computed block", and line 97 asserted that name. The same dump against the unmodified `release/7.19` client gives byte-identical output, so no client change was needed for this. ## Change The assertion now states the invariant instead of a column name: ```ts cy.get('.ht_clone_top .htCore thead tr th').then(($ths) => { const derived = [...$ths].filter((th) => th.classList.contains('dc-derived-header')) expect(derived.length, 'derived headers').to.be.greaterThan(0) expect(derived[0].classList.contains('dc-derived-first'), 'the first derived header opens the block').to.be.true derived.slice(1).forEach((th) => expect(th.classList.contains('dc-derived-first'), 'only the first derived header carries the marker').to.be.false) }) ``` It still fails if the marker is missing, if it lands on the wrong column, or if more than one column carries it - but it no longer depends on which variable the control table lists first. ## Verification ``` Running: derived-variables.cy.ts 5 passing (1m) ✔ All specs passed! 5 5 - - - ``` Local mock estate: `sasjs/server` desktop mode, JS runtime, mocks deployed with `sasjs cbd -t server-ci`, app served by `ng serve` - the same shape as the pipeline step. No SAS changes.
hermes added 1 commit 2026-10-27 22:22:51 +00:00
test(editor): assert the derived block marker, not a column name
Build / Build-and-ng-test (pull_request) Successful in 5m22s
Lighthouse Checks / lighthouse (pull_request) Successful in 20m58s
Build / Build-and-test-development (pull_request) Canceled after 17m25s
c463a4e03c
derived-variables.cy.ts:97 expected dc-derived-first on the REGION header,
because the comment assumed REGION opens the computed block. The grid follows
MPE_DERIVED order, and that order is LINE_VALUE, REGION, REGION_LABEL - so the
marker was on LINE_VALUE and correct. The spec asserted the wrong column, and
the development pipeline has been red on it since.

Dumping the header row on a local mock estate (sasjs/server desktop mode,
RUN_TIMES=js) shows:

  6 | LINE_VALUE | dc-derived-header dc-derived-first
  7 | REGION | dc-derived-header
  8 | REGION_LABEL | dc-derived-header beforeHiddenColumn htLastVisibleHeader

and the same dump against the unmodified release/7.19 client, so this was never
a client defect.

The assertion now states the invariant instead: at least one derived header, the
first of them opens the block, and no other one carries the marker. That holds
whatever order the control table returns the variables in.
allan merged commit fd272eec89 into release/7.19 2026-10-27 22:25:31 +00:00
allan deleted branch fix/derived-block-spec 2026-10-27 22:25:31 +00:00
Sign in to join this conversation.