Java TimeUnit: More than just a unit of time

My conception of time, my ability to distinguish between consecutiveness and simultaneousness - seemed subtly disordered so that I formed chimerical notions about living in one age and casting one's mind all over etenity for knowledge of past and future ages.

- "The Shadow out of Time", H.P. Lovecraft

Consider the case when you need to call a method that requires you specify a time duration, for example, specifying what the timeout should be for a service making a web call. Usually the time related argument is an int or long, with an inferred unit of measurement (usually milliseconds, but sometime seconds). As you may be thinking of a unit of measurement other than what the method wants, it becomes neccessary to do a conversion. For instance, to specify a timeout of 30 seconds may neccessitate that you actually specify 30000 milliseconds. This conversion is not difficult, but it is tedious (and can cause problems when maintaining code). The good news is that conversion doesn't need to be tedious (and, in some cases, may not be necessary).

Unit tests: the fallacy of 100% coverage

"The Hounds of Tindalos!" he muttered. "The can only reach us through angles. We must eliminate all angles from this room. I shall plaster up all of the corners, all of the crevices. We must make this room resemble the interior of a sphere."

- "The Hounds of Tindalos", Frank Belknap Long

I'm an ardent supporter of having unit tests for one's codes, having first hand experienced the benefit they give when you need to refactor code. As a result, one thing that really irks me are programmers who view unit tests as, at best, a necessary evil and therefore try to write as few tests as possible. To them, a suite of tests is good if the tests execute a lot of the code. If these programmers could achieve 100% code coverage, then they would feel their work is done: no more tests need to be written! While this belief might be true for some code, in general it does not hold true: for most classes, simply having 100% code coverage says nothing about whether the code is truly doing what it should do.