Video: Is TDD Dead? 4: Costs of Testing

April 5th, 2019

 

Is TDD Dead? 4: Costs of Testing

https://www.youtube.com/watch?v=dGtasFJnUxI

 

 

===

David

 

 

other half of trade-offs

things are not free

 

 

pressures and nudgings

 

 

1) over-testing

"never write a single line of prod code without writing a test"

multiples of lines of test code per prod code

what is the right ratio?

how many 9's ?

 

 

===

Kent

 

 

delta-coverage

how much does a test test which none others do

if you have multiple tests covering one behaviour, you have coupling

 

 

===

Martin

 

 

overshoot or undershoot

only care if it's too large

 

 

2) every line should have a test covering it

"if I screw up this line of code, will a test fail"

as long as one fails

indirect is ok

comment a line out, change conditional

 

 

1) only test things that can possibly break

 

 

===

Kent

 

 

ratio test<>prod

 

 

depends on coupling of your system

 

 

eg. compiles has high coupling

 

 

===

David

 

 

you say "150% -> 100%"

I'm ok with much less

 

 

===

Martin

 

 

calibration - goldilocks

 

 

too little:

can you confidently change the code, feeling if you screw something up a test will break

too much

whenever you change the code, you're spending more time on tests than on code

 

 

===

David

 

 

tuning:

developers

consultants

 

 

===

Kent

 

 

Who is the audience

 

 

===

David

 

 

top of authority chain

documentation REJECTED

tests REJECTED

code OK

 

 

red-green-refactor

red-green dopamine

refactor boring

 

 

pressure to push energy towards tests

 

 

===

Kent

 

 

when would you

keep the tests, lose the code

lose the tests, keep the code

 

 

===

Martin

 

 

tests = this is what it thinks it's doing

 

 

value = double check

 

 

red-green-refactor

matter of skill

 

 

dopamine = clean

 

 

===

Kent

 

 

===

David

 

 

tempting to focus on things easy to measure

speed

coverage

ratio

-> honey trap

 

 

overfocus on testing-infrastructure

 

 

TDD is very addictive practice

hardly been spoken about