[evilneanderthal]

I'm not sure I fully understood everything you were saying here.

But I would mention that unit tests give you a nice picture of what will break when you DO change your interfaces. The list of broken tests is your new task set.

This is a significant benefit.

[10ren]

I agree with you that tests will tell you when you break your interfaces. My position is that in some cases you don't want that.

mjd explains it well. Here's my attempt at elaboration:

It's only in a particular kind of project, at a particular stage: Imagine you are designing a project, in which you change the interfaces at the drop of a hat. Daily (or oftener). In this scenario, the "new task set" of the list of broken tests is extra work that increases the viscosity of your code. It's a distraction from your actual exploratory task, of trying out different interfaces. You are setting out to change interfaces, because you are experimenting with what they should be: that's your actual task. This only applies when you need extremely fluid code, and when it doesn't really matter if there are lots of bugs. Think of a poet daydreaming, or an artist sketching out a very rough outline, or the first prototype of an inventor (made with wax and strings).

[10ren]

I thought of another way to say this (not that you need it):

Sometimes you write code to throw away. James Gosling has said he does this. Fred Brooks said "build one to throw away". Novelists write drafts, artists draw sketches and sculptors carve studies (I was amazed to see that Michelangelo did several studies for his sculpture of David - full size, in marble!)

In contrast, tests are an investment in code. They make the code better, more reliable, more correct - more tested. They make it harder to throw away the code.