The biggest problem with unit tests is that writing and maintaining the detailed unit tests require about as much time as the program in the first place. Lots of work. Sometines you change one line that changes the results of 100 tests, and then you have to go through all of them and figure out, if it changed them in the right way or not.
Some of this difficulty can be reduced by making the test more high-level, running a more complete application and doing some action on a single aspect of it. It's kind of a balance between the detailed view and the overhead.
Also the original code for the low-level tests has to provide the hooks for the unit tests to access the internal state of the objects and check that it is correct. One typical way of doing this is by defining the wrapper classes. And then the rules are "no private anything, only protected; no final classes" etc, or these wrappers won't be able to access the state in the classes they wrap.
Joined: Apr 05, 2010
Adding to it, recently I find the integrated tests much more useful than the fine-grained unit tests. You still target the test toward one part of functionality, but if you run it in the context of the whole application, much more of the code gets exercised. Often this highlights some issues in a part of the code you've never thought of.
And the integrated tests usually take a lot less effort to develop than the detailed unit tests.