blockly: add concept and first initial tests for logic blocks

[stefan-hoehn]

This is the first attempt to add unit and integration tests for blockly components. I based my approach on what is currently implemented in other typescript areas and in particular what has been written in agent.md.

Based on the very few "blockly logic blocks" I have created tests which could become a "template" for all other blocks as well going forward.

The integration tests provide a more complex design to evaluate if the code created is like it is expected. For this particular situation I created the test like I previously did manually in a visual way where I wanted make sure that the "multiple logic block" could be added to an if statement ("outer constraint") and also creates the right content for itself (inner code expectation). I have currently tens of these (integration) tests in a visual way for other blocks locally in my personal setup which I like to eventually move into automated tests.

All the other "unit test" rather check if the block has been implemented correctly and also enforces other things like using the right coloring. In particular here I am open to a conversation if we really should check all of this or not. Only after we are through with this conversation, I will then continue to move on with more tests and maybe even add instructions to the agent.md to allow these kind of tests very efficiently.

@florian-h05 Feel free to give me a call, so we can have an efficient conversation on that.

[relativeci]

#5270 Bundle Size — 13.84MiB (~+0.01%).

b7fd17c(current) vs db441e9 main#5266(baseline)

Warning

Bundle contains 2 duplicate packages – View duplicate packages

Bundle metrics   1 change

	Current #5270	Baseline #5266
Initial JS	1.41MiB	1.41MiB
Initial CSS	0B	0B
Cache Invalidation	16.18%	25.93%
Chunks	697	697
Assets	816	816
Modules	2817	2817
Duplicate Modules	0	0
Duplicate Code	0%	0%
Packages	126	126
Duplicate Packages	1	1

Bundle size by type   1 change 1 regression

	Current #5270	Baseline #5266
JS	11.53MiB (~+0.01%)	11.53MiB
CSS	901.7KiB	901.7KiB
IMG	638.41KiB	638.41KiB
Fonts	526.1KiB	526.1KiB
Media	295.6KiB	295.6KiB
Other	847B	847B

Bundle analysis report Branch stefan-hoehn:blockly_add_initial... Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[florian-h05]

Just as a initial note:
We deliberately decided to leave out unit tests from the Maven build, as in some IDEs this can lead to very slow builds or build loops (IIRC @Nadahar).
Integration tests and all other UI tooling is run on PR and main push as dedicated GHA workflow.

[Nadahar]

Just to elaborate: It's not a problem with Eclipse, but with how the tests were being run. Maven have different phases, and tests are supposed to run in the "test" phase. That was not what was done, it was run during the "compile" or "package" phase I think. Those are correctly executed by Eclipse when rebuilding, tests are not.

It was decided that it was easier to just remove the tests than to integrate it "correctly" with Maven, and let the CI run them explicitly.

[stefan-hoehn]

Thanks for the clarification! Does that mean we "only" have to make sure that these tests here are run in the test phase? Was there a particular reason why this was (or is?) not the case at that time (or still ist)?

[Nadahar]

My memory is somewhat faded, but I think the reason was the NPM plugin that is used from Maven, and that it didn't handle it properly - or perhaps that it was done wrong in OH. Anyway, AFAICR, it ran tests and all together with the regular build.

If you can make the tests just run in the Maven test phase, I don't think there is a problem.