Testability has been (for 30 years=forever in software development terms) and always will be a large factor in measuring quality in software. Bad testability = bad design. Functional requirements are definitely not the end of story on software quality (for a deeper discussion, google for software quality, McCall, Boehm, ISO 9126, etc).
That seemingly simple relationship is hard earned knowledge, especially among application developers. Countless comments and thoughts are a testament to that fact.
However, testability is not defined by if and how you use a mocking framework, or other tools. Since testability is slowly gaining more and more exposure, the way it is being exposed seems to confuse.
It is in the nature of many computer enthusiasts to reduce skills and knowledge to tools in the form of software.
Need a great picture? Easy, get photoshop. Need a better personal economy? Quicken is the answer. Want to compose music? Cubase & Co will turn you into Mozart. Right?
And of course, if you need to improve quality via TDD - just get xUnit, a mock framework and you'll be a test development wizard in no time! Right?
Well, no. Neither testing nor BDD/TDD is not about using rhinomocks ("sorry" Ayende), just as creating music is not about Cubase ("sorry" Steinberg). Testability certainly has been around longer than NUnit...
In contrast, design issues such as coupling and other forms of bad dependencies are inherently bad things for testability (herr Jungmayrs dissertation puts it forward in a great way). Even more so, it is bad for software quality in general, not just testability. Again, it is something that we have "known" for decades. Even object orientation has little to do with it. Testability in the mainstream goes even further back than OO in the mainstream ("sorry" Bjarne). It has nothing to do with things like "OO purity".
Still, developers like shortcuts and some will fight these things every step of the way.
I think that the additional knowledge and competence required can be daunting, and that is why "highly OO" designs often are as bad and complex as "spaghetti code". Admittedly, even a well designed application can be hard to understand.
I am sorry to have to break it to some people, but whoever told you developing software would be easy, wasn't really being honest with you.
Seriously, "complex OO designs" are not necessary, nor required to support any xUnit framework. In some instances, you don't even have access to a framework - be it xUnit or any mock - and you just (lo and behold!) write tests as a normal app, to test your code. Which works. That means we're still not off the hook! Shucks! You still must provide decent testability and low coupling, in order to create unit tests, even though you're not using xUnit or any testing tool at all. Shoot!
On the use of Typemock, Lenny is right in that it is a wonderful tool for addressing the testing needs of legacy code, and that you naturally wouldn't create unit tests for a large existing codebase. NUnit provides a great testrunner. Neither requires testability to use. Neither guides us when creating code.
What I feel is very wrong, however, is using the capabilities provided by Typemock as an excuse to create bad quality, highly coupled and unmaintainable code. When you are starting anew, seize the opportunity! Do it right! If you've worked with getting quality up in existing code, introducing unit tests, and so on - you will appreciate the opportunity. If not, you need to rotate so that you do.
Typemock is a great tool and gives you alot of power. I think one should consider disallowing it in new projects, atleast until people start to get the mechanics of testing.
What are the downsides of Typemock? Oh, where to begin... To be continued... (picture "How the west was won" text on a grim James Arness face)