What code don't you test?

Question

Possible Duplicate:
How deep are your unit tests?

Ok, so it's common wisdom that it's impractical (and maybe not even preferable) to get 100% test coverage. In my experience, there's some code that's simply more trouble to test than it is practical to do so. I've kind of developed an intuition about this. But my team is sort of new to the whole test first way of thinking. I'm having trouble thinking of any guidelines on this subject.

I'll take that as a prompt to mean that maybe my intuition is wrong. So I'll pose the question to you guys: what code shouldn't be unit tested? Bear in mind that we're in legacy code land (at least in Michael Feathers's definition), and I'm trying to push a "test existing code as you go" approach.

Answer 1

Typically I don't unit test interactions with unmanaged code and almost never anything using HTTPRequest.

Answer 2

Getters and Setters

Anything that simply wraps a libary call and should throw an exception - yes I know we should test these but trying to create a broken network, or crashed DB server is just too hard IMHO.

Answer 3

The code I write most that I don't unit test is, in fact, the unit tests.

I think everything else should be testable, and I make an effort to architect it such that I can. The difficulties come with code relying on remote servers etc., and I try to mock as much of that as possible.

Answer 4

All code should be tested, but I agree its not always practical to automate those tests. You can, however, get pretty damn close to 100% automated test coverage if you design for testability, which test-driven development forces you to do.

Of course, 100% test coverage is not actually all that meaningful, as you might have tested that 100% of the branches in your code are exercised but you sure as hell haven't tested all the permutations of call order and data ranges.

GUIs are really hard to test - you might be able to confirm that some text appears on the screen when button A is clicked, but would your automated test notice that that text is bold when it should have been italic, or that it appeared as white on white?

Answer 5

The tests themselves shouldn't have to be tested, except when for example the verification code becomes unwieldy. This could happen especially when developing tests for code which is not well fit for testing.

Answer 6

Code that needs a service up and running, and 500 lines of code on a method, and not built on an interface is usually hard to test. You need to brake it apart, and extract dependences from it first.

Answer 7

As a quick answer, I would say you should really only heavily test blocks of code which have a high chance of throwing unhandled exceptions due to input. So, a function that shows a message box or reverses a string or creates and displays a form does not need to be heavily tested, whereas a function that takes a set of latitudes and longitudes and calculates the distance of the shortest path that includes all the points needs to be heavily tested with a wide range of input values (including totally invalid input data).

Knowing which kinds of functions are likely to fail out in the world and which ones aren't is the real benefit of experience.

Answer 8

I don't take the time to test any framework code (.NET, jQuery, etc.), no matter how much I swear that there's a bug in the framework. The assumption is that the framework code has already been rigorously tested, which lets you focus on testing your own code. This assumes, of course, that you are not building and testing said framework yourself.

Answer 9

Code that doesn't work? Thats the code that isn't tested right?

Answer 10

The things to focus on testing are the things with complicated logic. You wouldn't test a simple getter/setter because it's straight forward and it creates a lot of tedious programming which is frustrating. You want your developers to avoid doing tedious things, otherwise they get bored and do something else.

What you would test are those things that involve some kind of computation. Examples are things like formatting string data into a display format (like rendering HTML), computing values from input sources, object state changing methods (outside of simple getters).

Focus on the complicated things that take more than 10 seconds to write.

Answer 11

We typically don't test GUI; instead, we try to extract all of the interesting logic into a presenter, and then test that.

However, we do have some tests for our GUI units. These generally fall into two categories: (1) ancient code where the logic is tightly bound to the UI code, and we haven't taken the time (and risk) to disentangle them yet; and (2) times when we actually care about behavior that's GUI-only, like "make sure the third-party grid drops down the combo box automatically when you tab into a new cell".

Answer 12

I'd not test getters and setters in general (as far as they really only set/get a single field, and not have another logic attached).

Apart from that, I think it's hard to set up general guidelines.

Beginning with test-first, you always think "what a stupid amount of work and thinking about how I can test something before actually writing it" - and later, you're really happy that you did it because testing thta piece of code manually would have been ugly, and you could correct some wrong ideas about how to implement it even before doing so - because you realized it already when thinking about your test.

That said, yes, trying to attach tests to legacy code can be a real hard work, because ot's not laid out to be tested.

Still, as long as it's not tested, it cannot be easily changed and enhanced - it's basically unmanageable as soon as it's orginal author leaves the house (taking the docs in his mind with him).

So, for newbies, I'd say, everything bu getters and setters - until you're familiar with it and devlop the intuition to see what's really not needed to be tested (which still should be not really much!).