Why Most Unit Testing is Waste

[Daniel Rinehart]

Thought provoking article about unit testing:

http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

-- Daniel R. <dan...@neophi.com> [http://danielr.neophi.com/]

[Stephen Vance]

There's a good debate between Coplien and Bob Martin from a few years ago that elaborates on a number of the points. 

Stephen Vance

--
You received this message because you are subscribed to the Google Groups "Boston Software Craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to boston-software-craf...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christopher Beale]

Dunno - seems like more authoritative conclusions from another expert who has yet to really figure out the real "why" or "how" of what he's talking about.  He's positioning unit tests as if they are actually about testing (which of course they aren't.)  My guess is he's had little/no real hands-on experience with red-green-refactor, method extraction, class extraction, dependency injection, ...  In talking about the outmoded idea of unit tests as a testing technique, his conclusions are undeniably solid so yeah, I agree.  Don't write crappy unit tests after writing crappy code.  Makes sense.  There is much more exploring to do to really break through as to the real "why" and the "how" of test driving design with good behavioral micro-tests but it doesn't sound like a) he's aware of what he doesn't know and b) he's open to learning.  I've worked for people like that.

Cheers,

Chris

 

christopher beale

c 586.260.3400

 

“I am convinced that life is 10% what happens to me and 90% how I react to it... we are in charge of our attitudes.” – Charles Swindoll

[Erik Price]

I far prefer hammock-driven development to test-driven development.

e

[Christopher Beale]

ok, i’m definitely interested in learning that.

[Steve Berczuk]

On Tue, May 6, 2014 at 6:46 PM, 'Christopher Beale' via Boston
Software Craftsmanship

<boston-softwar...@googlegroups.com> wrote:
> Dunno - seems like more authoritative conclusions from another expert who
> has yet to really figure out the real "why" or "how" of what he's talking
> about. He's positioning unit tests as if they are actually about testing
> (which of course they aren't.) My guess is he's had little/no real hands-on
> experience with red-green-refactor, method extraction, class extraction,
> dependency injection, ... In talking about the outmoded idea of unit tests
> as a testing technique, his conclusions are undeniably solid so yeah, I
> agree. Don't write crappy unit tests after writing crappy code. Makes
> sense. There is much more exploring to do to really break through as to the
> real "why" and the "how" of test driving design with good behavioral
> micro-tests but it doesn't sound like a) he's aware of what he doesn't know
> and b) he's open to learning. I've worked for people like that.

Having spoken to Coplein about this, I'm pretty sure he "gets it" in
that he agrees that TDD is about design. What I get out of what he's
said about this is

1. Tests for the sake of testing are not useful. (I once worked at at
place where you could not commit code that was not written TDD style
and they same place also, at the time, saw little value in any
non-automated testing, so I see what he is saying...
2. Cope tends towards the provocative, and is countering the other
side of the Dogmatic TDD cohort

Having said all that, I still like doing TDD at times, and I like
having unit tests, even for trivial things, if the trivial things are
things that have caused a lot of head scratching post-deployment. So I
think if the article starts a conversation, that's good.

Steve

--
Steve Berczuk | steve....@gmail.com | http://www.berczuk.com
Twitter: @sberczuk
ADN: @spb
SCM Patterns: www.scmpatterns.com

[Colin Williams]

I saw that article originally as a link at the bottom of http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

Also interesting: https://plus.google.com/events/ci2g23mk0lh9too9bgbp3rbut0k …