least 'worth it' unit test you've ever written?

Question

On the SO blog and podcast Joel and Jeff have been discussing the, often ignored, times when unit testing a particular feature simply isn't worth the effort. Those times when unit testing a simple feature is so complicated, unpredictable, or impractical that the cost of the test doesn't reflect the value of the feature. In Joel's case, the example called for a complicated image comparison to simply determine compression quality if they had decided to write the test.

What are some cases you've run into where this was the case? Common areas I can think of are GUIs, page layout, audio testing (testing to make sure an audible warning sounded, for example), etc.

I'm looking for horror stories and actual real-world examples, not guesses (like I just did). Bonus points if you, or whoever had to write said 'impossible' test, went ahead and wrote it anyways.

Answer 1

Once I wrote a unit test to expose a concurrency bug, in response to a challenge on C2 Wiki.

It turned out to be unreasonably hard, and hinted that guaranteeing correctness of concurrent code is better handled at a more fundamental level.

Answer 2

@Test
public void testSetName() {
    UnderTest u = new UnderTest();
    u.setName("Hans");
    assertEquals("Hans", u.getName());
}

Testing set/get methods is just stupid, you don't need that. If you're forced to do this, your architecture has some serious flaws.

Answer 3

It sounds to me like the writing of a useless unit test is not the fault of unit tests, but of the programmer who decided to write the test. As mentioned in the podcast (I believe (or somewhere else)) if a unit test is obscenely hard to create then it's possible that the code could stand to be refactored, even if it currently "works".

Even the "stupid" unit tests are necessary sometimes, even in the case of "get/set Name". When dealing which clients with complicated business rules, some of the most straightforward properties can have ridiculous caveats attached, and you mind find that some incredibly basic functions might break.

Taking the time to write a complicated unit test means that you've taken the time to fine-tune your understanding of the code, and you might fix bugs in doing so, even if you never complete the unit test itself.

Answer 4

My company writes unit tests and integration tests seperately. If we write an Integration test for, say, a Data Access class, it gets fully tested.

They see Unit Tests as the same thing as an Integration test, except it can't go off-box (i.e. make calls to databases or webservices). Yet we also have Unit Tests as well as Integration Tests for the Data Access classes.

What good is a test against a data access class that can't connect to the data?

Answer 5

Foo foo = new Foo();
Assert.IsNotNull(foo);