Add unit tests for tag-system

[Zabuzard]

Overview

Implements and closes #213 . Adds unit tests to the tag system, i.e.

• TagSystem,
• TagCommand,
• TagsCommand and
• TagManageCommand.

The tests themselves should be rather self-explanatory.

Majority of changes in this PR are not logic changes but come from the fact that we made Config mockable, and hence had to get rid of the singleton - which bleeds into almost all commands.

Features

While at it, we had to implement multiple more general features from which other unit tests will also benefit in the future:

Database

We added a method Database.createMemoryDatabase(...) to conveniently use an in-memory database for testing. An usage can be seen in TagsCommandTest, where it is called @Before each test.

Mockito

The whole mockito test suite, in particular revolving around JdaTester has been enhanced and generally supports more calls now.

And we also added some bigger features to it:

Button events

In order to test button events, we added a JdaTester#createButtonClickEvent() method that returns a builder that can create mocks of the event, similar to how JdaTester#createSlashCommandEvent(...) works.

The API of this builder is very similar to JDAs Method interface and similar:

// Default message with a delete button
jdaTester.createButtonClickEvent()
  .actionRows(ActionRow.of(Button.of(ButtonStyle.DANGER, "1", "Delete"))
  .buildWithSingleButton();

or

// More complex message with a user who clicked the button that is not the message author and multiple buttons
Button clickedButton = Button.of(ButtonStyle.PRIMARY, "1", "Next");

jdaTester.createButtonClickEvent()
  .message(new MessageBuilder()
    .setContent("See the following entry")
    .setEmbeds(
      new EmbedBuilder()
        .setDescription("John")
        .build())
  .build())
  .userWhoClicked(jdaTester.createMemberSpy(5))
  .actionRows(
    ActionRow.of(Button.of(ButtonStyle.PRIMARY, "1", "PREVIOUS"),
    clickedButton)
  .build(clickedButton);

Command spies

There is now a method JdaTester#spySlashCommand(command) that makes it possible to work with a command that is spied upon and additionally is setup properly. For example, it works with a mocked component ID generator.

Member spies

We also added a method JdaTester#createMemberSpy(userId) that is able to create valid member instances which are spied upon. Useful for testing things that require members. For example buttons that have been clicked by a user different to the message author.

USER option for slash command events

We enhanced the SlashCommandEventBuilder and added overloads option(String, User) and option(String, Member).

So now it also supports options with types USER, not just String. For example:

Member member = jdaTester.createMemberSpy(1);

var event = jdaTester.createSlashCommandEvent(command)
  .option("id", "foo");
  .option("reply-to", member)
  .build();

To make this work, the implementation had to be changed a bit. Therefore, other types can now also easily be added in the future.

Setting the user who triggered a slash command event

The SlashCommandEventBuilder now has a method userWhoTriggered(user) that can be used to set the member who triggered the event. Useful for mocking, for example to adjust permissions of a user who wants to use the ban command.

RestAction mocking

JdaTester now has two methods to create success and failure mocks of RestActions. This can be very useful when testing stuff that involves calls such as TextChannel#retrieveMessageById or similar. Example:

var jdaTester = new JdaTester();

var message = new MessageBuilder("Hello World!").build();
var action = jdaTester.createSucceededActionMock(message);

doReturn(action).when(jdaTester.getTextChannelSpy()).retrieveMessageById("1");

or also

var jdaTester = new JdaTester();

var reason = new FooException();
var action = jdaTester.createFailedActionMock(reason);

doReturn(action).when(jdaTester.getTextChannelSpy()).retrieveMessageById("1");

Checklist

Unit tests

• TagSystem
• TagsCommand
• TagCommand
• TagManageCommand - raw
• TagManageCommand - create
• TagManageCommand - create-with-message
• TagManageCommand - edit
• TagManageCommand - edit-with-message
• TagManageCommand - delete

Mocking

• spySlashCommand
• createButtonClickEvent
• add USER as option to SlashCommandEventBuilder
• userWhoTriggered(user) for SlashCommandEventBuilder
• Config.getInstance() mocking
• RestAction<T> mocking (success & failure)
• Discord API exception mocking

[Heatmanofurioso]

I usually follow a convention on the Display Names of tests, where I describe my GIVEN, WHEN, THEN in the test name itself.

Would you think it's a good idea to adapt to that convention @Zabuzard ? Probably starting on this PR "hence me asking it here"

[Tais993]

If possible, could you make it so this PR becomes 2 commits.

1 updating JDATester, and ButtonClickEventBuilder etc
1 adding the tests

This makes imho more sense

[Zabuzard]

If possible, could you make it so this PR becomes 2 commits.

1 updating JDATester, and ButtonClickEventBuilder etc 1 adding the tests

This makes imho more sense

I beautified the commit history (no code changes). Cheers
(Its important to keep the Config change separate, since this will cause a lot of merge conflicts and that way resolving those will be simpler)

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication