Did you test your recommended way to get started testing own changes?
When I do what you wrote, I get an exception
java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7

Did you test your recommended way to get started testing own changes? When I do your what you wroteI get an exception java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7

That does not seem an issue with the test

I ran the build and it worked

Did you test your recommended way to get started testing own changes? When I do your what you wroteI get an exception java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7

can you tell me what I did

I ran the build and it worked

I just did what you described. Copied the class in the same directory, right-clicked the file and executed it. Not sure what I would be doing wrong. To verify if it's only my fault, please try to execute a bot in the same way as I did.

I ran the build and it worked

I just did what you described. Copied the class in the same directory, right-clicked the file and executed it. Not sure what I would be doing wrong. To verify if it's only my fault, please try to execute a bot in the same way as I did.

I mean I don't have a bot token at hand right now

but did you change the class name and set a token

I also ran the normal tests and it also threw an error. For some reason it seems like gradle doesn't like running with Java 17 in Javacord. When I switched to 11 it worked fine.
And regarding executing the test class, it seems suboptimal that the DEBUG logs are shown in the console, so the logger configuration has to be adjusted or better said seperated so each test directory has their own configuration.

Will see if I am able to do the latter part of your message

I also ran the normal tests and it also threw an error. For some reason it seems like gradle doesn't like running with Java 17 in Javacord. When I switched to 11 it worked fine.

And regarding executing the test class, it seems suboptimal that the DEBUG logs are shown in the console, so the logger configuration has to be adjusted or better said seperated so each test directory has their own configuration.

Would it be alright to add a .xml file for logging like https://github.com/YDWK/YDWK/blob/master/src/test/resources/logback.xml in the test folder. It says what logging you want and where from.

Would it be alright to add a .xml file for logging like https://github.com/YDWK/YDWK/blob/master/src/test/resources/logback.xml in the test folder. It says what logging you want and where from.

We already have a logging file and this will most likely not work because you will also affect the logging level for the normal tests, that's why I said the configuration has to be separated somehow.

Would it be alright to add a .xml file for logging like https://github.com/YDWK/YDWK/blob/master/src/test/resources/logback.xml in the test folder. It says what logging you want and where from.

We already have a logging file and this will most likely not work because you will also affect the logging level for the normal tests, that's why I said the configuration has to be separated somehow.

Can we leave that for a separate pr

Can we leave that for a separate pr

But then what's the point of this PR if it is not really suitable for getting started with testing? Then, I think using the current way to create a test class is easier than having to deal with the logging configuration.

Can we leave that for a separate pr

But then what's the point of this PR if it is not really suitable for getting started with testing? Then, I think using the current way to create a test class is easier than having to deal with the logging configuration.

but this serves as a template for a test class and to know where to test. Makes it easer.

Can we leave that for a separate pr

But then what's the point of this PR if it is not really suitable for getting started with testing? Then, I think using the current way to create a test class is easier than having to deal with the logging configuration.

but this serves as a template for a test class and to know where to test. Makes it easer.

I could look at how to make the logging work