Friday, July 24, 2009

Keep Your Privates Private

On my current project, some developers discovered that they could test private methods using reflection. I asserted my opinion(which of course rarely happens) that we shouldn't be testing private methods. My point was that my public methods are my interface to let others know how to use my class. My tests are a verification of that contract. If something changes to break that contract it will let me know. Its sort of a contract on a contract. So after a lively discussion about it, I did some research (I googled) and found that there is indeed some debate on the matter.
Instead of rehashing that debate, I would like to add another view, that once developers can test private methods, they do it without thinking of alternatives. I never say never, so I'm not totally against the idea of testing these private methods, but it just feels wrong. I think once developers have a test around a complex method they stop. My mantra is if its hard to test, then something is wrong with your design.
The methods I have seen with private methods tested usually have some side effects. They are changing class level variables or the arguments of the method without any return values. Sometime they are just encapsulating some complex behavior that should moved into another class.
Test Driven Development (TDD) is not so much about testability but about designing for testability. A application that is redesigned to be easily testable is an application with less coupling, more focused objects and less side effects of the methods.
I realize that with the pressures of deadlines and legacy code, its not always possible to refactor and testing private methods could be a solution to get more test coverage. I just think we should first try to refactor and only if that isn't feasible should we test private methods.
If you do find that you must test private methods, Bill Venners has a good article on testing private methods, I particularly like his translating the reflection exceptions into assert exceptions. He also has a good example of the kind of private methods that are hard to test.

Tuesday, July 21, 2009

Always Something to Learn

I am always ready to learn although I do not always like being taught. ~Winston Churchill

I'm always surprised at the number of people in the software industry that don't strive to learn. Programmers that brag that they don't touch a computer at home or read a computer book. A programmer that doesn't like to learn is like a doctor that doesn't like the sight of blood. I think that with a constant barrage of new frameworks, technologies and the pressures of deadlines we not only should always be learning something new, but its a necessary part of our job.

I understand it's not always useful to learn Widget 0.9 framework that will be obsolute when TheNextBigThing 1.2 comes out. But that's not an excuse to then not learn anything. There are still many things to learn to make you more productive.

What about the programming language you use, are you up on the latest features? What about just basic programming techniques? Reading code from open source projects or the the code of the language itself if possible is a great way to learn.

What about testing your code or learning different programming methodologies? What about your IDE of choice, do you know all the shortcuts and plugins that can help you?

Learning shouldn't be an either/or proposition. It should be more of a Return on Investment (ROI), if I invest (x) hours, I should be able to save (y) time. I find that learning time tested concepts give me more bang for the buck than learning the latest framework or technology. Also a better understanding of the concepts makes working with the frameworks easier.

Topics like testing, refactoring and design patterns seem to stay around longer. Also the books for these topics can be found fairly cheap in used, but like new condition on Amazon or Alibris, or if your lucky at you're local Half price bookstore.

The shelf life for a developers knowledge is extremely short, however if we concentrate on concepts that are time tested, ones that have been around for awhile, and topics that make us more productive, we should be able to maximize our learning and be more professional in our jobs.

By the way, I put together an Amazon list of some of the books I have enjoyed that haven't "depreciated" over time.

Wednesday, July 1, 2009

Re-Finding Tools in My Toolbox

As developers, especially Java developers, we are always looking for the next big thing. I like nice new shiny things as much as the next programmer, but I think its extremely valuable to learn the what our basic tools can do. We don't seem to study the basics anymore like Java, HTML, JSTL, JSP. I started this blog as a way to go back and make sure that I know the fundamentals of what I'm doing before I reach for another tool to solve my problem. Who knows I just might already have the tool in my toolbox.