Add unit testing for commands, JDA mock system

[Zabuzard]

Overview

Closes #152. Adds a unit testing framework for commands revolving around JDA mocks with Mockito.

Original proposal by @Heatmanofurioso, optimized and adjusted by me. (still quite some TODOs in there though, can be done in other PRs).

Also adds high unit coverage for PingCommand and DatabaseCommand.

Example

Basic usage example:

SlashCommand command = new DatabaseCommand(database);
JdaTester jdaTester = new JdaTester();

SlashCommandEvent event = jdaTester.createSlashCommandEvent(command)
  .subcommand("get")
  .option("key", "foo")
  .build();
command.onSlashCommand(event);

verify(event, times(1)).reply("Saved message: bar");

Details

It revolves around the class JdaTester which is basically a mock of JDA and friends. The class offers a createSlashCommandEvent method that, using a builder-pattern, enables users to create their own command events. Those events can then be given to command.onSlashCommand(...) to trigger the test logic. Testing is then done via Mockito, since the events are Mockito mocks.

The builder provides strong subcommand and option validation using the CommandData settings from command.getData(). That way, users will get runtime exceptions when trying to create wrong events, such as:

SlashCommandEvent event = jdaTester.createSlashCommandEvent(new PingCommand())
  .subcommand("foo")
  .build();
// throws because "PingCommand" has no subcommand called "foo"

The builder has quite some background bloat because unfortunately JDA does not provide utility to create events. The core of its logic is creating a DataObject with DataObject.fromJson(json). The JSON has to be in the format specified by the Discord API (see the actual payloads send by Discord), which we construct over a POJO bridge using Jackson.

Mockito

Note that the approach of Mockito mocking JDA is quite fragile. It is highly likely that adding any new command that uses some other features, will run into a JDA routine that has not been covered by the mock yet - causing NPEs and other annoyance. That means that anyone who wants to test their commands usually also has to spend some time on expanding the JDA mock.

Also, major updates in the internal API of JDA will likely break the mock, we are using their internal code (i.e. their ...Impl classes) directly here.

I do not see any nice way around that though - it is what it is.

[Zabuzard]

CodeFactor only complains about the // TODOs. They can be addressed in another PR though.

[Tais993]

This does make the current project a lot harder, creating commands just got a whole lot more complicated, so not sure how that's gonna go with less knowledged programmers

[Zabuzard]

This does make the current project a lot harder, creating commands just got a whole lot more complicated, so not sure how that's gonna go with less knowledged programmers

@Tais993
Testing commands is not a requirement. It is an option.
I am open for better alternatives but dropping optional command testing all together doesnt sound better to me.

The major problem with testing is that we expose JDA and its API to the user. We do not hide it behind our own API and hence also do not have control over it. Which is why Mockito seems to be the only option. (To be clear, I am not voting for hiding JDA, its just the reason why testing gets so nasty)

One advantage of this proposal is that writing the actual test is still simple, from which beginners will benefit. Maintaining the platform behind it is the obstacle, which experienced devs can take responsibility for - I do get your point though and you are right.

[Zabuzard]

History cleanup and added @Heatmanofurioso back into the history

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication