[plt-scheme] Re: [maybe off-topic] The theory of testing

>
> On well-run projects with good people my experience mirrors yours
> exactly. On less well-run projects with mediocre-to-fair developers
> I've experienced almost the opposite. I've had "seasoned" developers
> with years of experience look at me like I've got two heads when I
> discuss the merits of unit testing. Some of these "two-head"
> conversations happened even after bugs were found said seasoned
> developer's code. The lengths these developers will go to "save" a few
> minutes because they see writing unit tests as "slowing them down" is
> truly mind-boggling. I've been programming professionally for almost
> 15 years and I'm still surprised when it happens.
>

Yep I can well believe it, but as you say they think unit testing will
slow them down, which goes back to their perception of how their
productivity is being assessed which goes back to how they are being
managed. I see Test Driven Design as a means of hoodwinking
programmers into testing by making it seem and feel like a coding
activity - which is consistent with their pre-conceived notions of
productivity which derive from how they are managed.

>
> > People do what they like on personal projects, but in an industrial
> > setting, testing practices and their success and failure are
> > determined and driven by the project management and their perceived
> > priorities, not an individual developers beliefs.
>
> I think it comes down to the culture of the individual project team .
> If the team places value in unit testing practices then testing
> occurs. If not. no-one, not project managers nor edicts from
> management can make it happen. People will come up with a thousand
> reasons why they don't need unit testing.
>

Again I agree, but the thousand reasons they come up with are usually
variations on time constraints (imposed by you know who) or the
subsequent testing phase that will supposedly bail them out. Another
(and this is more difficult to argue against) is that change is
inevitable so in effect they are developing a throwaway prototype so
there's no point in testing it.

>
> If you force them they'll
> pay it lip service at best and write crappy tests which fulfill their
> own "unit tests are bad" prophecies.
>

If you lay out a procedure for how things should be done and people
circumvent that and something goes wrong that is traceable to their
code then the question is whether such developers should prosper or
even survive in the organisation.  If you have a culture where  the
speed to release was rewarded above the correctness of the code, I can
well see it happening. You talk about the culture of individual
project teams, you can afford that on small projects, but not on large
ones where a project teams contribution is one cog in a big wheel of
development. There you need some homogenity across project team
practices.

If a project team is involved in some greenfield project that maybe no-
one else understands,  an individual culture may also hold sway, but
generally I still think these things trace back to management and what
developers perceive their values to be.