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

On Aug 25, 2:30 pm, "Kevin A. Smith" <ke... at hypotheticalabs.com>
wrote:
> On Aug 25, 2008, at 3:24 PM, wooks wrote:
>
>
>
> > On Aug 25, 1:07 pm, "Grant Rettke" <gret... at acm.org> wrote:
> >> Regarding my take on XP and Unit Testing, you're preaching to the
> >> choir!
>
> >> What I'm sharing with you guys is based on what I've seen on *many*
> >> projects.
>
> >> Wooks, here is what I meant:
>
> >> %80 of developers don't know why unit tests exist, don't trust them,
> >> won't do them.
> >> %80 of managers don't know why unit tests exist.
> >> Inevitably "issues" occur. Developers cite the unit tests as being
> >> "useless", which becomes the justification for no longer maintaining
> >> them.
>
> >> That is the norm.
>
> > It may have been the norm 20-25 years ago, but it's not the norm today
> > and hasn't been the norm for a long time.
>
> > In the 70's and early - mid 80's the industry absorbed itself with
> > problem of how to develop applications more quickly - hence you had
> > the era of CASE tools, the emergence of "4GL's" , wizards and RAD
> > tools. The major problem then shifted to one of knowing whether what
> > had been developed was right, hence you saw the emergence of "QA" or
> > "testing" as a software engineering (sub) discipline in the latter
> > part of the 80's (or at least it became more common).
>
> > Developers have always  known they should unit test and why they
> > should do so. There may be issues with the degree of formality and
> > repeatability of the process but they know what they should do. So do
> > project management. When there is a project deadline to meet and
> > pressure from above to meet it, it's the testing that gets squeezed
> > and management tend to takes a punt on releasing  code thats not been
> > tested as thoroughly as it ought. The decision to release then
> > becomes  an exercise in risk management - someone decides the
> > likelihood of inadequate testing leading to a problem and tries to
> > assess the impact if it does. That is the norm, albeit the testing and
> > risk management are applied with varying degrees of formality from
> > site to site.
>
> > Everybody knows you should test (and not just unit test) and the
> > consequences of not doing so and everybody knows what corners are cut
> > in the face of project deadlines and everybody knows the consequences
> > that follow.
> > _________________________________________________
> >  For list-related administrative tasks:
> >  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> Sadly, it's been my experience that this line of thinking only applies
> to the *good* developers. There just aren't enough of those. . .
>

I worked as a testing contractor for the best part of 14 years and did
so on both sides of the Atlantic.

It was extremely rare to come across a developer who either didn't
know to/believe in testing their code. That they may not always do so
is more to do with the way they were managed and how their
productivity was assessed, than how "good" a developer they were.

Their management may have focused on how quickly code was turned
around or how many lines of code per day they produced and ignored
their bug counts or the number of times they had to correct and
release a piece of code.  You've heard the phrase "There's always time
to do it over but never time to do it right". Some management may have
encouraged a lax attitude to unit testing on the misguided grounds
that there would be a testing phase later in the project that would
catch those bugs or that there was no time for it.

My experience was that developer who didn't believe in testing their
code, quickly changed their attitude after a series of bugs were
exposed in code they had written.

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.