Re: [extremeprogramming] What has changed for you over the past 20 years?

"James Grenning" <[email protected]> Wed, 04 Dec 2019 22:13:36 -0500
Newsgroups gmane.comp.programming.extreme-programming
Message-ID <[email protected]>
I warn people of the potential dysfunction of code coverage as a goal.  
Like Mike said: take out the checks and you still have 100%!  For those 
tests you might as well buy a test generator; then you can get the 100% 
test coverage bonus for meeting your goals.

I suggest to people in code influenced by TDD and design skill, you get 
areas of 100% and 0%.  Something that is a mix is probably a design 
problem.

This is what happens to my code.  I have areas that are suitable for TDD 
and have 100% coverage (not because that is the goal, that is just what 
happens). Areas that are not suitable for TDD have 0% coverage and 
complexity of 1 or 2. They tend to be areas that do not change.

Cheers! James

--------------------------------------------------------------------------
James Grenning - Author of TDD for Embedded C - wingman-sw.com/tddec
wingman-sw.com
wingman-sw.com/blog
twitter.com/jwgrenning
facebook.com/wingman.sw
[![wingman 
software](http://www.wingman-sw.com/images/wingman.png)](http://wingman-sw.com)

On 4 Dec 2019, at 17:11, Slava Imeshev via Groups.Io wrote:

> Of course we mean good tests. I’m doubtful that it’s possible to 
> claim a good test without good coverage.
>
> Slava
>
>> On Dec 4, 2019, at 2:05 PM, Mike Bowler 
>> <[email protected]> wrote:
>>
>> We rapidly get a collection of tests that increase code coverage 
>> without testing any actual behaviour. I’ve seen whole test setups 
>> with few or no assertions.  This is then worse than having low test 
>> coverage because we can’t trust any of it.
>>
>> Then when the team is in the habit of writing garbage tests, that 
>> starts to leak into their production code and quality starts dropping 
>> there too. They care less about the quality. I expect this is some 
>> variant of Social Proof or the Broken Window Effect.
>>
>> I can’t think of a single case where imposing a high code coverage 
>> number on checkin,  up front, has resulted in the team writing better 
>> code and I can think of many cases where the reverse is true.
>>
>> Now, the one case that I have seen work is where the team starts a 
>> mandatory code coverage based on where they are today and very 
>> gradually increases the mandatory amount over time to slowly improve. 
>> Although even that causes problems when new people are brought onto 
>> the team or new teams take over that code base.
>>
>> Mike Bowler
>> Agile & Technical, Coach and Trainer
>> Cell: 905 409-7052 
>> <tel:905%20409-7052>www.GargoyleSoftware.com/mike_bowler 
>> <http://www.gargoylesoftware.com/mike_bowler>
>> www.UnconsciousAgile.com <http://www.unconsciousagile.com/>
>>
>> Ask about our Certified Scrum Developer (CSD) training classes 
>> <http://www.gargoylesoftware.com/training/csd>. In-house and public 
>> classes available.
>>
>>> On Dec 4, 2019, at 4:51 PM, John Maxwell <[email protected]> wrote:
>>>
>>> On 12/04/2019 04:47:58 PM, Mike Bowler wrote:
>>>>> Yep. TDD is a holly grail. Just having a policy not to check in 
>>>>> any
>>>> code without 100% unit test coverage does wonders to quality.
>>>>
>>>> I can’t tell if you meant that as sarcasm. I’ve seen that 
>>>> policy put
>>>> in place and the “quality” that results. I expect many of us 
>>>> here have
>>>> seen that disaster.
>>>>
>>> I haven't. What's the failure mechanism?
>>>
>>> --
>>> John Maxwell  KB3VLL  [email protected]
>>>
>>> "Personally I'm fond of using Dedekind cuts for representing the 
>>> Reals,
>>> but it gets cumbersome to use when balancing one's checkbook."
>>>        -Charles Haynes
>>>
>>>
>>>
>>
>>
>
>
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#160407): https://groups.io/g/extremeprogramming/message/160407
Mute This Topic: https://groups.io/mt/39418691/2417047
Group Owner: [email protected]
Unsubscribe: https://groups.io/g/extremeprogramming/leave/4902963/619838065/xyzzy  [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-