Automated tests for all syntax and changes. about skript

[hbbaker]

Hi! I'd like to help add tests for existing functions. I'm new to opensource and I'd like to ask a few questions regarding how these tests should be implemented. Thanks!

[sovdeeth]

Hi! I'd like to help add tests for existing functions. I'm new to opensource and I'd like to ask a few questions regarding how these tests should be implemented. Thanks!

See https://github.com/SkriptLang/Skript/blob/master/src/test/skript/README.md

[Moderocky]

Hi! I'd like to help add tests for existing functions. I'm new to opensource and I'd like to ask a few questions regarding how these tests should be implemented. Thanks!

Sure! It's fairly simple but if you'd like somebody to walk you through the process please contact one of us in our Discord server :)

[APickledWalrus]

@Moderocky I think it would be a good idea to establish stronger naming guidelines for tests. What do you think about requiring tests to start with (or just be) the name of the expression. For example, the name of the test for ExprBlockData would just be ExprBlockData. Some files have multiple tests, so in those cases we could use "ExprBlockData - " to differentiate the test names. We may also want to consider whether having multiple tests in one file is practical compared to just "sectioning" tests using comments.

[Moderocky]

For example, the name of the test for ExprBlockData would just be ExprBlockData.

The base test is currently named after the syntax class (like ExprBlockData -> block data)

Some files have multiple tests, so in those cases we could use "ExprBlockData - " to differentiate the test names.

These are usually named <class name> (<thing that requires its own test>) so something like block data (legacy) or block data (1.18+) for example.

I think this is fine since when the test fails that makes it fairly clear what's not working.

What I'm more concerned about is the assertion messages - most testers have taken care to make all of the messages unique (so you can work out which one failed from the message) but ideally I'd like the testing system to be able to determine the line that was the cause of the failure so we don't have to rely on that.