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.