Basically you have three choices when it comes to  embeddable Java LDAP servers (at least open source). First of you have Sun’s OpenDS, they have a page dedicated to Tips and tricks for writing unit tests. I have to say that I’m not very impressed by OpenDS. Don’t take me wrong it might be a fantastic LDAP server, but it certainly does not give me the feeling of being very embeddable! First of all the documentation refers to a mysterious class TestCaseUtils. I’ve checked builds from version 1.0.something to 1.2.something without finding it. The second drawback is that OpenDS is like a flesh-eating-configuration-monster sent back in time to kill the spirit of any developers getting near it. It comes with a 2000+ lines ldif config file, which is supposed to work for servers running embedded as well. It would be nice if they could provide a minimal configuration file for embedded use. To me it complained a lot about errors in the bundled schemas. Oh that’s right you need to set up a directory structure for config files, schemas and locks. Again, not very embeddable!

The second and third choise is ApacheDS. You have the newer version 1.5. with support for fancy things like triggers and stuff and you have the older 1.0 series. Both LDAPv3 compatible. The project is very well documented and they even maintain something they call Apache Directory Studio, which is a graphical LDAP GUI based on Eclipse. Very nice! If you don’t need the fancy stuff implemented in the 1.5 series I really recommend that you go for the older 1.0 series for your unit testing. You’ll find jars in Maven repos and it’s really simple to get started. It just works the way you expect it to! Just follow this guide and you will be unit testing your LDAP code in no time.

At the time I’m writing this 1.5.4 is the newest version of the 1.5 series. They have a guide for doing unit testing with 1.5 as well, but due to some problems it won’t work with 1.5.4 so you’ll have to build the trunk for your self or track down a Maven snapshot repo (good luck!).

Happy testing!

You could obviously change your methods access modifier from private. By making it public you’re breaking encapsulation and by making it protected you’re making your API less intuitive. Don’t do that.

Another way to go about this is to create a new class that’s extending the one with your private method

I find the easiest and most convenient way achieve unit testing of private methods is reflection. Some of the features the Java reflection API offers is access to private fields and invocation of private methods. This sounds like something useful for our problem, by using reflection we’re able to test our private methods without making any changes to our classes.

class TestSubject {
 
	/**
	 * For some reason we want to unit-test this method
	 */
	private int adder(int numberOne, int numberTwo) {
		int answer = numberOne + numberTwo;
		return answer;
	}
}

This is the method we want to test, here is how we go around to actually do it:

TestSubject subjectInstance = new TestSubject();
Class testClass = subjectInstance.getClass();
 
// Find the method. getDeclaredMethod will give you any methods from that
// class whether it's public or not where getMethod only will give you
// methods with public access. The first argument is obviously our method's name,
// where the next arguments are the formal types of the adder methods parameters.
Method adderMethod = testClass.getDeclaredMethod("adder", int.class, int.class);
 
// Method is a sub class of AccessibleObject if we don't call it's
// setAccessible method we'll get an IllegalAccessException when we
// try to invoke it on our object.
adderMethod.setAccessible(true); 
 
// Invoke the method on our instance of TestSubject
int answer = (Integer) adderMethod.invoke(subjectInstance, 2, 2); 
 
// assert answer = 4

It’s more or less just to plug it into your testing framework of choice and you’ll have unit testing of your private methods.

But hey! Do you really want to unit test your private methods? Doesn’t it give you that bad feeling in your stomach. You know the feeling you get when you’re code smells a little? I mean, a part of the reason for those methods being private is that they’re subject to change.

It’s the oldest oo rule in the book, hide the inner working of you’re classes so you later can change the inner workings of the class without exposing any change to your clients. What you really want to do is to unit test the public methods using those private once. If you find that difficult it might be a little hint that you should consider changing your design a little in order to improve it’s testability.

Why did I bother showing you how to unit test private methods if I consider it bad practice? Well, sometimes when I’m working on complicated things I like to unit-test private methods while working on the class. And there might be situations where unit testing of private methods is the right way to go. Just be careful so you’re not writing a lot of tests you’ll waste a lot of time maintaining later!

Relevant Java API: Class, Method and reflect.

Happy coding!

By default it draws implementation of interfaces and inheritance and if you add some tags / annotations to your JavaDoc it will draw composition, aggregation, dependencies and navigable relationships as well. There are some undocumented options as well. I’ve used the Netty source code as a reference as it seems to be the project maintainer of Netty that’s behind ApiWiz (shoot me if I’m wrong).

I’m in progress of uncovering some of the undocumented features. If someone knows something I appreciate a comment below.

Example from the Netty project

Update: After digging through the source code (gotta love open source!) I found the documentation missing from the web page! This documentation shows how to add labels to the edges.

apiviz.uses
<FQCN> [<sourceLabel> <targetLabel> [<edgeLabel>]]
 
apiviz.has
<FQCN> [oneway] [<sourceLabel> <targetLabel> [<edgeLabel>]]
 
apiviz.owns
<FQCN> [<sourceLabel> <targetLabel> [<edgeLabel>]]
 
apiviz.composedOf
<FQCN> [<sourceLabel> <targetLabel> [<edgeLabel>]]

FQCN is short for “Fully Qualified Class Name”.