http://e24.no/medier-og-reklame/article3079677.ece

find . -empty -type d | xargs –replace=EMPTYDIR touch “EMPTYDIR/.empty”

This will put an empty file named “.empty” in every empty sub directory from where you’re standing.

Please make sure that you copy the line correctly. There is an double hyphen before xargs’s replace parameter and regular double quotes around the touch argument.

Anyway, this finally pushed me to have a look at alternatives. I’ve been wanting to try out Mercurial for some time now and this pushed me over the edge. My first impression is really good! I obviously have to spend some time getting used to the distributed model, but it seems like it might be worth it. Everything was looking rose red until I figured out that it doesn’t support tracking of empty folders!? It does make sense when I think about their architecture built up around sha1 sums, but I still think that it’s strange. I often create a directory structure before I start coding. The workaround seems to be creating empty files inside each folder, which sounds a little annoying to me.

That’s it for now. Man it felt good to shout and scream a little about Subversion!

Even Grails support is coming along with support for Grails 1.1. Rumors has it that even debugging is supported now! Nice work!

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!

I can’t believe that they’re still releasing disks with this problem! It has to affect their reputation in a very negative way!? I’m curious to read reviews of their new Vertex series. They’re supposed to have 32-64MB on board cache that should remove some of the iops problems.

Guess it’s just left to hope that we’ll see cheap SSDs without iops problems soon!

http://www.w3.org/2005/Incubator/emotion/XGR-emotionml-20081120/

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!