Good idea :) interesting results so far... I personally would love to know what test runners people use/prefer as well.
I'm a db dev who dabbles in web, so I see mocks as a bad idea (I *want* to include the database in my testing, speed be damned), but the web devs will likely be forced to adopt the defacto standard (by popularity) when they get there. For instance, our shop standard is NUnit because it's the most popular (and thus has the most support/literature available) but I've been using Gallio/MbUnit 3.x -- nobody has complained because I don't think anybody else actually writes unit tests.
I am writing unit tests for EVERY bug in my brownfield app and I intend to use TDD for my next greenfield. The team is soon going to have a build / CI server. I'm evaluating a few approaches / frameworks for unit testing our databases as well (we're data-intensive). **IF** I switch from db-dev to web-dev, I might start using mocks... but for now I prolly won't.
Cool poll Roy, interesting results. I too would be interested in seeing which testrunners people use (I use the R# testrunner).
@Duncan
Testing all the way to the db is great for integration tests but these shouldn't have to be run every time you make a small change to the code - that simply increases the friction of development with unit tests rather than decreasing it.
Slow tests / test suites are what kills the desire to run them often. The more often the unit tests are run, the sooner they catch problems in the code, the less likely you are to have forgotten the context within which you wrote the code.
wrt tests for bugs, mocking means you no longer have to set up the database (and any other piece of infrastructure) to create the exact scenario, rather you can create mocks and tell them exactly what to return. While this doesn't seem like much gain when it is a single call that creates the error, it truly shines when you need to execute a complex sequence to get the bug to manifest.
@Neal
I'll probably amend my position when I start writing applications as opposed to the database and/or once I get a decent sql unit test framework in place and/or once anybody else on my team actually bothers to execute a suite.
You should add one for what methodology your shop uses...and whether they are contractors or IT employees, I think that's where you'll see some REAL interesting numbers.