The trouble appears to be in your arguments. To them, the old code and
fix approach does appear to work (and even if it doesn't, they don't
know any better).

How much time do you have to do this; can you take them for a week or so
(perhaps in pairs)? If so, I would have them work on OSS TDD projects
like Castle, NHContrib, CCNET, ...; talk with the devel lists there to
try to find something projects that they think would take ~3-4 days (you
will be slow going at first because it takes time to grok the codebase).
That should be enough to get them acquainted with the methods.

Also, you need to start keeping track of statistics like build
failures/week, checkins/day, build failures/checkin, bugs fixed/week, #
of known bugs in each deployed version, # unknown bugs in each version
(figured out retrospectively), etc, and get them figured out on a per
dev basis and a per project basis (assuming you have multiple visual
studio projects, if not; do that first) if possible. After you have some
stats, have the devs work on some of the projects in a TDD style and you
probably will need TypeMock to jump start some of your coupling issues.

While doing all of this; you need to make sure the build environment is
working for continuous integration; with the click of a button (at most;
at some point it may be possible to go all the way on a schedule based
on dev checkins, but I wouldn't start there esp without tests) you
should be able to get the latest code, build, run a set of automated
tests, and if all successful deploy to production (your process may have
more steps depending on your environments). Until you are rid of
infrastructure impediments and you have a reliable (ie no human
interaction as we make mistakes), repeatable and automatic build and
deployment process, you will not get very far with any automated test
process (and if you try, you will hurt developer productivity and be
seen as causing friction within the workplace).

Finally, just because you don't have the developers practicing TDD
doesn't mean that you cannot be writing tests. Get comfortable with a
tool like Watin and start writing any automated tests you can think of;
every time there is a reported bug, write a test to reproduce it. Find
bugs yourself as well. Get the devs pair programming (in my experience,
this is much easier to convince people of). Have the team meet often for
code reviews where you discuss the best checkins of the week (get the
devs to brag about their work and be proud of it) and possible
refactoring that can be done (have pairs set up at the meeting and have
each pair think of refactorings that can be done in 10 mins or less
which will result in a better codebase; then have the pair do the
refactoring on a projector while everyone else watches and makes
suggestions).

Above all, make it fun (or you will not be there long as the devs will
disassociate themselves with you) and make sure you are recording
productivity gains (maybe try a 2-5 min talk with managers of what went
well and what didn't; make them feel like a part of the team and never
say no to them [make your no sound like a yes] when they have a
suggestion; also try to make it so they think they had some of the ideas
and let them take credit for some of them).
Dimitar Dimitrov wrote:
> Hi everyone,
>
> I just got a new job at a dot com considering switching to agile
> development and part of my job description as Build and Test engineer
> is to help with the process. I am afraid, that just writing unit
> tests, what I will be supposed to do without applying TDD is pretty
> much useless and won't bring the expected higher quality.
>
> Do you have any ideas how can I convince and show them that the old
> code and fix approach just won't work even with a bunch of integration
> tests and TDD is the way to go
>
> I would appreciate any tips and ideas.
>
> Regards
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>