Friday, November 10, 2006
Unit tests, documentation, Google code search and Vernor Vinge
...plus a little bit of Eclipse at the end.
As you can guess by the title, this post jumps around a bit...
It all started yesterday, as I was reading JM's comment about using unit tests as documentation -- this was in response to ealden's post on whether we should be testing simple methods -- I was struck by how true this was when I was searching the Jakarta Commons Beanutils documentation on what classes/methods I could use to convert a Java bean to a Map of its properties.
I spent a lot of time doing google searches and found some discussion on copyProperties -- but this static method on PropertyUtils was only good for copying from a bean to another bean or a Map to a bean (quite the opposite of what I wanted.) I also found another static method called "describe" but the documentation didn't give me a clear idea as to what it did ...
I finally hit on using Google Code Search and the search pointed me to the static method "describe" that does exactly what I wanted -- and this information came from the unit tests on the describe method.
Which brings me to a conclusion:
Which then reminded of a another post in Steve Yelvington's blog a few days ago about Vernor Vinge's (an author I really like) novel (A Deepness in the Sky, I think) and how in the future we will no longer have programmers writing code, but more like "Programmer archaeologists" who search through vast code libraries searching for existing code they can retrofit into a solution.
If I remember correctly, "Programmer-at-Arms" was a position on their starship staff for a programmer who searches for weapons systems which they then build on the fly...
Which brings me to my Eclipse plugins wishlist:
It's all these kinds of stuff (Open source, code search, eclipse plugins) being invented today that will really bring us closer to a future when we programmers will be doing less of reinventing the wheel and get focused on making the wheel do something useful -- like making the Internet useful for porn... but that's another topic for another day :D
As you can guess by the title, this post jumps around a bit...
It all started yesterday, as I was reading JM's comment about using unit tests as documentation -- this was in response to ealden's post on whether we should be testing simple methods -- I was struck by how true this was when I was searching the Jakarta Commons Beanutils documentation on what classes/methods I could use to convert a Java bean to a Map of its properties.
I spent a lot of time doing google searches and found some discussion on copyProperties -- but this static method on PropertyUtils was only good for copying from a bean to another bean or a Map to a bean (quite the opposite of what I wanted.) I also found another static method called "describe" but the documentation didn't give me a clear idea as to what it did ...
I finally hit on using Google Code Search and the search pointed me to the static method "describe" that does exactly what I wanted -- and this information came from the unit tests on the describe method.
Which brings me to a conclusion:
In a world where we tend to write lots of code with very little documentation (beanutils had javadoc documentation, but it wasn't enough) , it may be that unit tests are the ONLY documentation we have describing our internal application APIs...
Which then reminded of a another post in Steve Yelvington's blog a few days ago about Vernor Vinge's (an author I really like) novel (A Deepness in the Sky, I think) and how in the future we will no longer have programmers writing code, but more like "Programmer archaeologists" who search through vast code libraries searching for existing code they can retrofit into a solution.
If I remember correctly, "Programmer-at-Arms" was a position on their starship staff for a programmer who searches for weapons systems which they then build on the fly...
Which brings me to my Eclipse plugins wishlist:
- a plugin that allows me to right click on the error message that shows up on the console (or maybe even the Junit error message) and context menu will pop up and allow me to either:
- go to the code that was the source of the error message
- or, search google for the error message - this usually gives me a clue as to the cause.
I usually do either one or the other anyway - having a plugin makes the task a lot more convenient.
- A plugin that will allow me to do google code searches not just on web, but use the Google desktop to search through the code on my local hard drive as well. We spend a lot more time trying to understand code written by others... seeing how the code is used just makes our task of learning how to use APIs of all the libraries so much easier...
It's all these kinds of stuff (Open source, code search, eclipse plugins) being invented today that will really bring us closer to a future when we programmers will be doing less of reinventing the wheel and get focused on making the wheel do something useful -- like making the Internet useful for porn... but that's another topic for another day :D
