Who writes 'Tests' for their plugins

Lately I have been reading a few articles about the importance of unit testing in java programs and began wondering how this could carry over to bukkit plugins easily.

http://geekswithblogs.net/jboyer/ar...hy-unit-testing-is-funndashand-important.aspx

So who uses tests for their plugins, how do you do it with bukkit plugins (since plugins aren't exactly self contained apps).

 

Define what you mean by 'Test' ? Like using them before you release?

 

Yes before the plugin is released it must pass all the test cases. The idea is that when you build you plugin, your ide/compiler/maven etc runs a series of tests on all your methods to make sure that the the Expected output matches the Required output.

Silly example to make sure that that your tester's multiply method works as expected. This example used JUnit - a popular java unit testing library.

Code:

[At]Test
public void testMultiply() {
 
// MyClass is tested
MyClass tester = new MyClass();
 
// Check if multiply(10,5) returns 50
assertEquals("10 x 5 must be 50", 50, tester.multiply(10, 5));
}

 

Larger plugins including one I'm working on it's good practice. I'm planning on running them once I've got my Nexus server setup with Jenkins.

 

How do you get the tests to run since important things like events are generated by craftbukkit during runtime. I'm really keen to try testing but can't get my head around doing it when plugins are not self reliant applications and methods/events are generated via other programs i.e the PluginManager.

 

if its a command, send the command for the console to run then monitor the events and see if they are what you ant. same for the events, manually fire them and see what you get back out.

 

That's not unit testing. That's sounds like black box testing that must be done manually with craftbukkit running which can't be done [easily] through a continuous integration server such as Jenkins.

 

I should actually be using them, but I decided not to because over 95% of my code deals with objects that require a live server running. For example: Blocks, Worlds, Type comparison, etc. Adding to that, most features change dynamically (constants, for example), making a test kind of useless.

I think the only thing I should make tests for is the MathUtil class in BKCommonLib. It is good practise, and I've done it in other projects where it proved to be very useful, but most of the time you write it once, it works, and then the test is never really used again. Code doesn't magically change...

If I had the choice, I would go with "No, I debug/test my code after I have written it, a test does not improve that". Tests, if done well, are not boring at all.

If you are dealing with object (de)serialization, logic, math (such as vectors) or other core functionality, I do recommend writing tests. Otherwise it is quite hard to find out what went wrong all of a sudden. Adding to that, projects usually introduce tests when there are multiple people working on it. Let's say that not everyone tests the changes they just made

EDIT

Adding to that, I actually perform my tests while the server runs. (runtime tests). For example:
Checking whether all packets are implemented
Checking whether all packets are handled by the packet listener hook

 

Not too sure yet, I'll need to give it a look at when I get to that stage. I'd assume something to do with using the tests in Bukkit.

 

That's quite interesting creating run time tests using reflection to solve the 'craftbukkit live code needed' to run the by the looks of it. I have been meaning to learn how to use reflection.

I also stumbled upon this thread http://forums.bukkit.org/threads/how-to-unit-test-your-plugin-with-example-project.23569/ which looked quite interesting where 'mock' objects such as events, blocks might be generated with the maven plugin called "Mock" which seems to have changed quite a bit since the time of writing though.

 

Timatooth
Runtime errors are the perfect runtime tests anyway. Just test all your functionalities of your plugin onEnable, it avoids random runtime errors occurring 'some time in the future'.

Also, NEVER FORGET to handle situations that you don't expect. If you end up with a dead entity in a spawn handler method, you should be aware of this, and deal with it appropriately. If something should really be impossible to occur, log a warning so you are at least aware of it. Think of catching NPEs. Example

 

Who needs a live server when you can mock the Bukkit objects you want to test with?

http://forums.bukkit.org/threads/how-to-unit-test-your-plugin-with-example-project.23569/

NM, Timatooth already mentioned that thread. But the concepts there still very much apply - Mockito is a great tool.

 

Boot server > Try.
That's how it's always been for me.

 

Of course ALL devs test their plugins at least on a local server before they release them.

 

Unit Testing is verrrrry important and extremely powerful. You can test really hard to reproduce "weird" cases and see if your plugin behaves correctly.
Sadly Unit Testing is very cumbersome with the Bukkit Api as you have to use MockingFrameworks and spend a lot of time overriding/mocking certain methods... Also you can't test if an Event that should have been called by Bukkit actually got called, you can only test if that Event got called how your plugin would have behaved...

 

I will definitely try out this mock object creation when I find the time in my [to be decided] future bukkit plugins.

 

I have been mostly skimming through the thread and don't know if it has been mentioned before.

Test Driven Development (TDD), you write the unit test before you write the actual working code. I have never used it myself but from what I have read about it it will make sure you cover pretty much your entire project.