Add ExprAbsorbedBlocks test

[F1r3w477]

Problem

The Skript project has low test coverage. The ExprAbsorbedBlocks expression, which relies on the SpongeAbsorbEvent, had no automated tests.

Solution

This PR introduces robust tests for ExprAbsorbedBlocks.

• Tests are broken down into simple, single-block absorption scenarios for each cardinal direction.

• Each test runs in an isolated location to prevent contamination during consecutive test runs.

• A cleanup and teardown process is used in each test block to avoid contamination.

Testing Completed

skriptTest

Supporting Information

This test was particularly difficult to stabilize due to limitations in the test runner's parser and race conditions in the server's block update queue. The final script structure represents a robust pattern for handling asynchronous, physics-based events.

---

Completes: none
Related: #6158

[bluelhf]

Thanks for contributing to Skript's test coverage :) While this test is probably okay as–is, a timing-based approach is not the right solution to ensure cases don't collide.

IIRC blocks are metadata holders, so you could use a metadata tag to link a sponge block to a specific test case and check it in the event — this way the test also can't fail if an unrelated sponge happens to absorb blocks (though that is at best unlikely)

There's no need to check cardinal directions individually, just one test case that checks that the list of absorbed blocks is correct should be enough.

[F1r3w477]

Thanks for the feedback and the suggestion to use metadata. It's definitely a more elegant approach in theory.

After extensive debugging, the current implementation (using physically isolated tests with timing) was the only way I could create a test that is 100% stable and correctly fails the build when an assertion is broken.

I agree it's not the most concise solution, but it provides full test coverage where none existed before. As the contributing guidelines mention, "Tests don't have to be good code - often, testing edge cases pretty much requires weird code." This seems to be one of those cases where a more direct method was needed to work around the test environment's quirks.

I'm happy to continue exploring other options if you have a specific syntax in mind that avoids the parsing errors, but for now, this version is fully functional and reliable.

[Absolutionism]

Tests cannot have delays in them wait ... as the testing environment shouldn't be delayed:

I'm also not sure about this approach for testing the event. Might need to be a JUnit test instead.

[F1r3w477]

This test is unable to run without waiting. If we want there to be no waits, somewhere we will need to document that this is untestable.

[Absolutionism]

This test is unable to run without waiting. If we want there to be no waits, somewhere we will need to document that this is untestable.

Well, in my posted screenshot, you can see the event is still being fired from the other tests as you have no delay between the start through cleaning up and setting block to water and block to sponge.
Your first test has a wait 1 second before clean up, which ends up making the rest of the code for that test not execute.

Granted, it seems that the event will be fired without having any delays. I'm not sure if using an event in a non-junit testing environment is something that should be done. Would like to see what other team members think though.

[F1r3w477]

Granted, it seems that the event will be fired without having any delays. I'm not sure if using an event in a non-junit testing environment is something that should be done. Would like to see what other team members think though.

Sounds good, absorbed blocks is only accessible from within the event, so if others agree, then this is not testable in this context.

[sovdeeth]

Why exactly are delays necessary here? I would expect the absorb event to be fired when the block is placed. Also, try to avoid changing blocks far from spawn, since it requires loading/generating new chunks and slows tests down.

[F1r3w477]

The assertion assert size of absorbed blocks is 1 with "Sponge should have absorbed 1 block" will intermittently read absorbed blocks as 2 if I remove waits.

My assumption is the test processes faster than the server processes the water physics changes. The test failure tends to be on consecutive test runs when using quickTest.

I can move the block setting closer to the test-location, I'll hold off on adjusting the test until we work through the concerns about waiting and using the event in the test.

[APickledWalrus]

There doesn't need to be a test for each direction. Just picking one and using it will be fine (it's out scope for this syntax anyway). As mentioned above, waits are not possible in tests.

If you have just one test, setting some blocks to water and then setting a sponge (which will trigger the event) should be fine. I don't think a JUnit test is necessarily required (though it wouldn't require the world modification/cleanup)

[F1r3w477]

The test works fine from one side if we don't wait. I updated the test to test from one side as @APickledWalrus suggested, and removed the waits.

If we need to test absorption from more than one side, I was unable to get it to work without making the test wait. As it sits now, there are no waits, we only absorb from one side, and the test takes place at test-location.