A controversial alternative for you - don't use mocks!
Instead do integration testing because really as soon as you are using the SharePoint OM that is what you are doing.
Put as much of your logic in library assemblies that can run from outside a request Context (overload constructor to pass in either HttpContext or SPWeb).
Setup a server/site (VM preferably so you can rollback and make new instances easily) just for unit tests and run against this. (VMWare Server is free)
If you running continuous build you should be able to set it to run automagically and report results. Alternatively some batch file magic with the open source nUnit or your tool of choice to run the tests as soon as a new .dll is copied over on a PostBuild step.
The disadvantages
You've got a bit of work setting up
data for your tests (though is it
much more than getting mocks
working?)
Not everything can be tested like this
May take a little longer to run, but if running as part of a continuous build is that a problem?
More discipline needed in a team to avoid stepping on other peoples toes.
The advantages
Your testing against the real SharePoint OM with all its baffling inconsistencies and special cases (if you were being unkind you may call them bugs ;)
Who knows what parts of the OM behaviour could subtly change when new service packs / cumulative updates come along, this should help catch any breaking changes.
- When SharePoint 2010 comes along you will be able to run your tests against both 2007 and 2010, see what changed, make sure your library works against both versions (if appropriate to your project)
The trade-offs for all projects are different, but for my projects I prefer the security of knowing I am testing against the real thing - call me old fashioned if you will!