I’ve found bugs in my own code (and test cases) by seeing that certain setters or getters were not being called during testing. Had a unit test been written purely to cover those getters and setters, I most likely would not have found those bugs.

Unit tests which exist purely for the sake of increasing your code coverage can often do more harm than good.

@Fabrizio: Clover, (http://www.atlassian.com/software/clover/) provides Context Filters to have certain blocks of code excluded from your coverage figures. You can even define your own so you can exclude all getters/setters if you wish.

@Michael:
“Finally, code-coverage should be able to report coverage percentages that either include or exclude getters and setters. Then one would know the wheat from the chaff.”

The latest release of Clover (2.2.1) now reports on the percentage of your code that is excluded via a Context Filter, thus making it possible to do what you want. Have a look at the text below the stats in the header of this sample report
http://downloads.atlassian.com/software/clover/samples/checkstyle/index.html

Just to drop a bomb on this convo- I never, ever ever unit test. Not one line, not one class. Why? The historical reason is, I’m a UI developer, most of my code is UI based so when unit testing hit, I went *sniff* … *sniff*… hmmm….not for me…

Non-historically, I *really* think it’s useless, though, as I say I’ve never actually DONE it. I actually take it as a virtue that I could *sniff* … *sniff* and decide it’s silly pretty quickly and not look back (much.. or hard) .

For me, it’s one of those technologies that came along in a huff and frenzy, proclaimed the world was its stomping grounds, and gained a lot of adherents who spend a lot of time worshiping at its altar. A lot.

Here’s my argument:

You’re not going to pump water through all conceivable pipes because you can’t. If you don’t understand that (but yo probably do) you probably have some foundational CS still ahead of you, (just like most everyone else).

In fact, you’re only testing for use cases you can think of, which is what you programmed for in the first place. You’re not *really* testing for anything outside of what you expect. In fact, if your code is clear, short simple well-named methods and coherent objects, you can go farther towards proving that your code will work as expected- farther than your unit test busy work will get you.

Here’s my Modus Operandi.. …ready?

I look at each and every line of code and ask myself- why would this not do what’s expected? Yep I sit there and and contemplate each line of code, and i say “hmmm… what could possibly go wrong that doesn’t represent a catastrophic failure on the part of either an outside library or the computer system?”

And I leave little proof-notes to myself in front of my methods which signify the reason why it can’t go wrong. I have about 30 or so so far. I have the typing of them automated as macros in my IDE.

I am never wrong. Ever. Over the course of 8 years, three since I’ve been doing this, (before I was just really really careful) three bugs have escaped me and gotten up to QA and one has shipped. And, no, I am not writing scripts for web pages or anything of that sort. My code is in Fortune 500s company-critical project offerings and the DOD.

I never unit test because it’s not the best way to ensure my code doesn’t have bugs and it’s not the best use of my brain power. Your intelligence and the understanding of the deep semantics of your program which only you can posses is far more able to detect bugs and many times more sensitive to bugs caused by an error in logic and unstated assumptions than unit tests are or are ever likely to be.

I never unit test.

Anything.

Ever.

So …. there.

Using something like JiBX (instrumentation) instead of Castor (refelction) makes the code cleaner because I don’t have to compromise on encapsulation at coding time. A developer can’t call the instrumented code directly because its not there. It doesn’t exist until after compilation. This means developers are less likely to (lazily or inadvertently) introduce inappropriate dependencies and coupling.

It’s not a perfect solution for the reasons you point out, and I wouldn’t use it for absolutely everything, but giving up on final fields and encapsulation (my definition of encapsulation rather than yours ) is even less ideal in my opinion.

It can be tested but, just as for getters and setters that don’t have their own tests, you’d have to test it indirectly by testing the code that uses it.

The instrumentation approach also often comes with a big performance advantage over reflection-based techniques.

Oh, yeah, that’s going to raise my confidence in my code. Code I can neither test nor read. Bytecode instrumentation IS breaking ALL encapsulation, by definition. Bytecode instrumentation is the universal pick to every encapsulation you thought you locked… a hacker’s dream… a black hat’s a-bomb.

I mean, come on. Let’s be rational.

Developers shouldn’t test getters/setters: unit-test frameworks should (insofar as possible), via a configuration option or annotation. It should be as easy as possible and, indeed, not given much merit as a metric.

The unit-test frameworks (or code-coverage etc) should report on the number of getters/setters tested and the total number. This posts asks “do you have too many getters/setters?”. Good question: why not have the ability to report on it, in its own right? Again, this is not a report for the CTO.

Finally, code-coverage should be able to report coverage percentages that either include or exclude getters and setters. Then one would know the wheat from the chaff.

You are right about Swing. Even without the getters and setters, UI code is hard to test well. Using something like FEST (http://fest.easytesting.org/swing/wiki/pmwiki.php) gets you some of the way there but I’m never really satisifed with my UI tests.

As for the Java Beans conventions (no-arg constructors and getters/setters). I’ve been thinking for a while that they are outdated. They made sense 10 years ago, but a lot of libraries have moved beyond the need for such clumsy conventions by using bytecode instrumentation to avoid having to compromise on encapsulation and invariants in your classes.

Now, covering getters and setters becomes important so you don’ run into the opposite mistake: ah, well, there’s a 25% missing coverage, but it’s getters and setters, while maybe the lack of coverage is in another place. This could be addressed in a different way if we had an annotation such as @IgnoreCoverage that prevents coverage tools to take some method into account, but somebody could misuse that.

At last, you’re right about having too many getters and setters, but here the problem is with specific technologies: e.g. if you have JavaBeans based stuff (which is a huge set of things, from Swing to JSF to JPA) you need to have a good number of getters and setters (and for Swing this means that you need also property change listeners, which indeed is a good thing to test).