Saturday, July 21, 2007

Unit Testing Private Methods

So I've always thought that when it comes to writing unit tests against private methods, you have two options; use reflection, or break encapsulation. However, I just read an article that discusses this very topic in a good amount of detail. It points out 4 options for testing private methods.

If you're just interested in a summary of those 4 options, keep reading. Otherwise, here is the article I came across.

1. Don't Test Private Methods

  • If you're testing the class's non-private methods, then the private methods are being tested indirectly. You can maintain a high confidence level in your code w/o unit testing those private methods.

  • Feeling the need to test private methods may indicate that those methods should be moved into their own class. There they would become non-private (easily tested) and become reusable as well.

  • 2. Break Encapsulation
  • Changing the method from private to package-access is probably the quickest and easiest solution to testing private methods.

  • Seeing a private methods tells you something. When it's package-access, it doesn't speak so loudly.

  • 3. Use Reflection
  • Using reflection (java.lang.reflect), you can bypass encapsulation and gain access to the private method you'd like to test.

  • Your tests are more verbose. You've got to gain access to the private method before you can test it.

  • 4. Use an Inner Class
  • An inner class inside the class you're testing will have access to the private methods.

  • Your production class contains more than production code.

  • My $.02
    I really don't like the idea of using a nested test class, but I'd love to hear arguments promoting this option. Also, I don't like sacrificing encapsulation for the sake of testing. If you want to test the private method, do it right and use reflection. Other than that, I'm sure indirectly testing private methods has its time and place, but how often is determined by how you write your code.

    Thursday, July 5, 2007

    Sun Certified Java Programmer

    So, I'm getting ready to start working on my 2nd Java Certification, Web Component Developer. I can remember when I used to question whether or not getting a certification was even worth it. I heard a lot about how certifications don't prove anything. Anyone can memorize some material and pass a test.

    I decided to work towards the Java Certified Programmer certification anyway. I made up my mind that I would at least improve my Java skills, which at the time I had only been working with Java for 6 months or so. After a few months reading SCJP Sun Certified Programmer for Java 5 Study Guide, taking practice tests, and putting my newfound knowledge into practice at work, I became a Sun Certified Java Programmer.

    There was no question. Taking the certification was with out a doubt, extremely beneficial. The biggest factor was the amount I learned about the Java language. This was especially helpful being a newcomer to Java. Plus, it does take more than just memorizing material to pass this certification. It takes an understanding of key Java concepts and OOP, in-depth knowledge of several Java 5 features, and the ability to put these things to work.

    If you're new to OOP and working with Java, or just new to Java, I strongly recommend working towards the SCJP certification. It will build your Java skills and add to your resume.