[INFRA] Rework the integration tests about CSS and style API interactions #2743
Assignees
Labels
chore
Build, CI/CD or repository tasks (issues/PR maintenance, environments, ...)
Milestone
Comments
tbouffard
added
the
chore
tbouffard
added a commit
that referenced
this issue
Aug 28, 2023
Previously, when applying the "CSS" API, the implementation ensured that the cell's original style was cached (for any subsequent reset) without any additional CSS classes. In fact, this was not necessary. Storing styles in the cache with additional CSS classes information posed no problem. When the style is reset, the value retrieved from the cache is updated with the CSS classes currently applied to the cell. This works just as well if there are no CSS classes as if there are. This additional check has therefore been removed. The tests verifying interactions between the "CSS" and "Style" APIs have been improved. They confirm that the removal of this coupling is legitimate: - Introduce a dedicated test file for these tests. - Previously, they were stored in the file testing the style update at template level. - This change provides an explicit way of identifying API interaction tests and a better separation of concerns. - Add a dedicated test to check the impact of resetting the style after a CSS and style update. This proves the uselessness of the coupling described above. covers #2803 closes #2743 --------- Co-authored-by: Souchet Céline <[email protected]>
github-project-automation
bot
moved this to Done
in Day to Day Board (bpmn-visualization)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://github.com/process-analytics/bpmn-visualization-js/pull/2732/files#r1225424168
We could/should create a dedicated file to store the tests about the interactions between the 2 APIs.
The checks about the CSS are currently done only by checking the DOM. As we override the mxGraph code to make mxGraph add the CSS classes, so we must keep DOM tests.
But we are updating the CSS classes directly in the mxGraph model, so we could add new tests to directly check the mxGraph model.
Note that this should be done before implementing #2803 if we're adding more tests to make sure we've looked at all the cases involved in the refactoring.
The text was updated successfully, but these errors were encountered: