Alright... for super small projects I don't think it makes a ton of sense to unit test a project, but for some bigger ones it can be very helpful. What is unit testing? In short, it's making sure your methods do what you think they are doing. Sure you can test in game. But that can be tedious. Plus it's not repeatable all the time nor good for regression. Example project functionality In my example project I have created a plugin that does the following: During the player join event, if the players name begins with "P", send them a message. Otherwise do not send them a message. Yes it's a dumb project. Feel free to run it on your server if you so desire that functionality... Crappy way of testing Now how can I test this? Normally I would compile, start up my server, go into my client, and see if the message comes up. My Minecraft login doesn't start with a "P" so I would not get a message. Now I either have to change my code to the letter that is the beginning of my minecraft login to test the other case, or find somebody whose name does start with "P" to login to my server. Kind of a pain either way. So... unit testing with Mock Objects is a good way to do this. You still *should* go into the game and ensure various things are working. But unit testing will make you feel like it's working as desired for the most part. Better way of testing Since most of Bukkit is filled with Interfaces and Abstract classes, it's really hard to instantiate them. With a mock object though, you can in a sense. You might think, "well that's a lot of fake data I have to generate!" and you'd be wrong. In this instance all we care about is the players name. We need to test it in the onPlayerJoinEvent(). So first, we make a mock "PlayerJoinEvent" object. PlayerJoinEvent has a fair amount of methods. The only one we care about is .getPlayer() though. So we tell our mock event that when .getPlayer() is called on it, return our mock Player that we've also made. With the player, we also know we're only going to call .getName(). So we tell that mock player object that when .getName() is called on it, return this String. Then we send our event into our method. Now of course we have no client to actually see the message. So how to do we know if the message was sent? That is what verify is for. We still have a reference to our mock player object. So we ask the mocking library to verify that .sendMessage() was called on our player. We can give it specific text to check for or just anyString(). Likewise for our other player whose name does not start with P, we can check that that method was not called on the player. A header to break this section from the prior one Mock objects for your plugin are *not* meant to test the functionality of Bukkit. They are meant to ensure that when Bukkit calls these methods that it does the codepath you expect. If Bukkit's sendMessage() method is jacked up then there's not much you can do about that in your plugin. However you can ensure that the correct code path was called. Once you have a good amount of testing in place and users report errors, add new test cases for those errors to ensure they never happen again! Also, by rerunning your test cases after a bug fix, you can ensure that you have not broken other functionality during your fix. As another advantage, you have unlimited "Player" objects so you can even test what happens when multiple players are using the plugin. I know I know... write MORE code? Trust me... this extra code will save you a ton of time and headaches. No more, "Well I fixed the issue, I hope it didn't break anything else" compile/submitting. Some people even write their test cases before they get into the code (see Test Driven Development). This is not the solution for everything, but is a good tool to have access to. The link to the project header Anyway that's enough long windedness... here is the project: https://github.com/Pandarr/PluginTesting Libraries used PowerMock with Mockito JUnit 4 Bukkit (duh) Test Passed! Test Failed! I changed the .startsWith() to look for "C" instead of "P". The first player was supposed to get .sendMessage() called but did not, so the test fails.