My unit test suite runs in ~500ms. I run it every single time I save a file. In fact, it's set up with a filesystem watcher to do this automatically and announce the result to me via growl.

The faster your test suite, the more often you can run it, and the faster you get feedback on your code.

You can combine this with a healthy integration test suite, and only run the unit tests.

Validation rules is a good example, if I want to test that my user input validation rules are correct, I don't need to do this through the entire application frontend - I can just check those rules in isolation.

>The faster your test suite, the more often you can run it, and the faster you get feedback on your code.

In all likelihood, the faster it is, the more tightly coupled it will be. You're simply exchanging computing power for brain power (refactoring tests when you refactor code), which is nearly always a bad trade off.

Usually my unit tests are tightly coupled to the module they're testing, but the modules themselves are loosely coupled from the rest of the system.

In most cases I want to preserve existing behaviour, so I don't want any existing tests to fail.

I'll add tests for the new behaviour in the relevant modules, add code to make them pass, and then if necessary update the glue code / integration tests which cross the boundary.

Pretty much by definition, a refactor of code should not change its behaviour. My tests usually assert on behaviour observed at the boundaries of modules, so they should still pass during refactorings.

> Pretty much by definition, a refactor of code should not change its behaviour.

Quite precisely by definition, perhaps for other reasons as well :-P

> My tests usually assert on behaviour observed at the boundaries of modules, so they should still pass during refactorings.

I find the kind of refactoring that most desperately needs the support of tests is changing the boundaries of the individual units. Unit tests can still arguably be useful there in making me clarify the changes I'm making to my interfaces... but they do need changing, and I can't be quite as confident that nothing is breaking if I'm changing both code and tests in tandem.

This sounds hellish, I don't want red things flashing in my terminal while I'm in the middle of changing some function signatures; I know it's broken, I haven't gotten around to writing all the boilerplate to convince the tests I know about it yet though.

I'm with GP about integration tests.

Growl doesn't flash red things in the terminal and nobody says you have to use Growl notifications if you don't like them, but this really has nothing to do with the usefulness of unit testing.

Sometimes I'll hit save to confirm that the tests I expect to fail are doing so.

Sometimes I'll wait until I've finished changing all those function signatures until I hit save.

Yes, but I can run unit tests while I'm coding. Waiting for a check-in is far too late. If I've broken something, it's more helpful to let me know about it ten seconds later, rather than hours later, when I've pushed my change and broken the build.

Some integration tests can perfectly well be run on similar terms.