Synchronizing shared expression tests with backend #2917
Conversation
…ction has shared tests
… referencing a data model not seen in the layout
olemartinorg
added
the
kind/other
| describe('DisplayValue tests', () => { | ||
| for (const [type, config] of Object.entries(getComponentConfigs())) { | ||
| if (implementsDisplayData(config.def)) { | ||
| it(`Component '${type}' should hava e matching test in functions/displayValue/type-${type}.json`, () => { |
There was a problem hiding this comment.
Hehe
| it(`Component '${type}' should hava e matching test in functions/displayValue/type-${type}.json`, () => { | |
| it(`Component '${type}' should have a matching test in functions/displayValue/type-${type}.json`, () => { |
| // inside this expression, because it will simply traverse the entire layout looking for expressions. | ||
| notAnActualExpression: expression, | ||
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| } as any), |
There was a problem hiding this comment.
Kan caste til typen det burde være i stedet? 🤷♀️ ev object?
There was a problem hiding this comment.
Den typen finnes ikke, det er litt av poenget 🫣 Men jeg ser at object funker, så det får bort behovet for eslint-disable iallefall.
| // This makes sure that the expression is never evaluated, as it is not a valid property. All properties | ||
| // that can handle expressions will be evaluated in the hierarchy generation, but errors from there will | ||
| // not effect the actual test here. Still, DataModelsProvider will find the reference to any data models | ||
| // inside this expression, because it will simply traverse the entire layout looking for expressions. |
There was a problem hiding this comment.
Har lest denne kommentaren 10 ganger og forstår fortsatt ikke helt 😬 er det mulig å forenkle på noen måte? Kortere kan forøvrig ofte være enklere.
There was a problem hiding this comment.
Usikker på om kortere er enklere å forstå her, om denne kommentaren var uforståelig. Det forklarer jo hvorfor vi må gjøre dette her, og kobler på dypt inngående detaljer til flere ting (NodesProvider, DataModelsProvider osv).
Hva med denne?
This makes sure that the expression is never evaluated, as it is not a valid property. All properties
that can handle expressions (like 'hidden') will be evaluated during hierarchy generation, but errors
from there (such as unknown extra properties like this one) will not cause test failures here (so doing
this is safe). DataModelsProvider however, will recursively look inside the layout and find anything
that resembles an expression and load the data model it refers to. In other words, this makes sure we
load any data models that are only references in the expression we're testing - not elsewhere in the
layout. For an example of a test that would fail without this, see 'dataModel-non-default-model.json'.
It has only a Paragraph component with no expressions in it, so without injecting the tested
expression into that layout, DataModelsProvider would not load the data model that the expression refers
to, and the test would fail.
|
Description
I compared the folders with those in
app-lib-dotnet, and updating tests to match.A few notes:
_experimentalSelectAndMap,displayValue,externalApi,formatDate,hasRole,linkToComponent,linkToPage,textandvalue).argv, and made sure to test that every expression function has a folder with shared tests.Related Issue(s)
Verification/QA
kind/*label to this PR for proper release notes grouping