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

On Aug 25, 2008, at 7:10 PM, wooks wrote:

> 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.

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.

>
>
> 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. 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.
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme