I think we must be agreeing to disagree here, or we are
agreeing to agree and missing it entirely in the
translation.
My post was to highlight that there is an art to writing
good automated tests that no tool will help you with - I
deliberately didn't mention TDD as that is another art
in it's own right.
If anything - tools are the problem here - a bit more
focus on some really basic principles would pay off long
before a few integration tests on badly written code.
When you can write a clean set of unit tests that have
real value, you won't need to be writing code that is
tightly coupled, nor would you want to ... or ....
Honestly Roy, would you write new code that is tightly
coupled knowing you can fall back on tooling, or would
you write it by nature in a loosely coupled way? To me
both have the same up front effort, the loosely coupled
way pays large dividends later on (like today when we
had to consider moving our application search engine to
another server, which will be nearly trivial due toit
all being loosely coupled already)
I think that you've found the crux of it: a path of “all
or nothing”. which for most people begets “nothing”.
Oh man. I hope you're asbestos undies are fully
deployed.
One can tell by the vehement responses of many people
against this idea that the idea strikes them on some
sort of emotional level.
I'm really not sure what the fear is that is causing a
reaction that seems out of proportion to the gvien the
subject matter. Sure, I don't want to have to come
behind noobs and clean up their code, but why all the
emotion?
It's very surprising to see the vehement and sometimes
caustic responses to what, in a nutshell, is the idea of
breaking things into more granular pieces. Sure, it's
not optimal, but to imply that one who learns to ride a
bicycle with training wheels will be unlikely to then
learn how to ride a motorcycle seems a bit paranoid.
Risking teaching noobs unit testing without a good
understanding of OOD techniques such as SOLID, etc. is
not going to place us in a worse situation than we have
now where the noobs aren't even creating the first unit
test.
I've been reading this discussion with a lot of
interest. I'm someone who would love to do unit testing
but the barrier to entry is much too high. 90% of the
code I write interacts with outside resources (database,
active directory, files, etc.) I'm told you can't unit
test that - those are integration tests.
When I look for information or examples on unit testing,
I either have to buy into all of the methodology (TDD,
SOLID, etc.) or I'm told that what I need to test isn't
unit testable.
I would love to see a good example of how I could write
unit tests for the Active Record pattern. We have 100s
of classes that instantiate an object that represents a
row in the database with methods to insert, logical
delete and update a row. The classes also have a number
of shared methods that return a table of rows that match
some criteria. How in the heck do I unit test that? Once
we get that data we bind it to a grid. Again, where's
the unit test there? It's n-tier. The data comes from
sql, via a business tier to the presentation. So if
you'd like to make some progress with one company with
about 50 developers, show me how to do that, and we'd
get 50 people doing unit tests.
I'm tired of seeing unit test examples on how to verify
that something calculates price correctly. How do I unit
test that my log message made it to the database?
I could even get my management to buy into letting us
have time for the learning curve, if I could come up
with a plan and some solid examples that our more junior
developers can model. But, until I find them, we'll just
bumble along without unit tests because what's out there
takes too much time to assimilate.
I think we've lost sight of our priorities in the agile
movement. Roy Osherove helps to redress the balance in
his recent recent series of posts on unit testing. But
my concern isn't just about making the tools
approachable. The much bigger issue is...
I had a little time today, so I downloaded Isolator 5.1.
I've used TDD on previous projects, but on my latest
one, there are only UI automation tests.
I looked for something to test in the project and the
thing I picked definitely doesn't follow all of SOLID,
among other issues, it uses the HttpContext.Current
directly.
It took a little time, but I was able to get a test up
and running; If I write a few more of these test, I'll
be able to refactor the design to something a little
more solid.