TDD is dead...

[Konstantin Ignatyev [e-mail] [seajug]]

@George
Here is the link to DHH quest against TDD
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

http://david.heinemeierhansson.com/2014/test-induced-design-damage.html

And also lovely videos of debates between DHH and Kent Beck moderated
by Martin Fowler
http://martinfowler.com/articles/is-tdd-dead/
--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate
between forty to one hundred species, erode seventy-one million tons
of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase
their population by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement
Needs a Strategy for Reforming Universities and Public Schools. New
York: State University of New York Press, 1997: (4) (5) (p.206)


------------------------------------
Posted by: Konstantin Ignatyev <kgignatyev-***@public.gmane.org>
------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Jason Osgood [e-mail] [seajug]]

I’m happy to see any testing activities. Even if its just kabuki. Baby steps.

Also, factor in the Railed by Ruby (dynamic programming language) perspective: comprehensive testing mitigates not using a real compiler.

Lastly, I worked thru the TDD book. Strategy works as advertised. It’d might even work in the real world, if I ever work on something I already knew pretty well. But that’s never been the case. I’m always making things up as I go.


When possible, I prefer programming from the outside in. What "outside in" shares with the TDD strategy is writing an API from the perspective of the client (code). The exact opposite of today’s dominate strategy of turgid software architectesque design pattern abuse lost in the murky agility swamp of ultimate despair.

If TDD does nothing more than make devs consider the client code perspective during design, then it’s a win in my score book.

Post by Konstantin Ignatyev kgignatyev-***@public.gmane.org [seajug]
@George
Here is the link to DHH quest against TDD
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
http://david.heinemeierhansson.com/2014/test-induced-design-damage.html
And also lovely videos of debates between DHH and Kent Beck moderated
by Martin Fowler
http://martinfowler.com/articles/is-tdd-dead/
--

[Nimret Sandhu [e-mail] [seajug]]

Post by Jason Osgood zappini-***@public.gmane.org [seajug]
Also, factor in the Railed by Ruby (dynamic programming language)
perspective: comprehensive testing mitigates not using a real compiler.

"comprehensive" is the keyword there. If you don't have that right then
your customers will be doing your QA when they get runtime errors :)
that's assuming that companies have a well fleshed out
unit/integration/functional test strategy and implementation which is in
lockstep with feature implementation/requirements.

Post by Jason Osgood zappini-***@public.gmane.org [seajug]
Lastly, I worked thru the TDD book. Strategy works as advertised. It’d
might even work in the real world, if I ever work on something I already
knew pretty well. But that’s never been the case. I’m always making things
up as I go.

from my experience the value in TDD is directly proportional to the
crispness of the requirements; even for the unknown stuff.

Post by Jason Osgood zappini-***@public.gmane.org [seajug]
If TDD does nothing more than make devs consider the client code
perspective during design, then it’s a win in my score book.

my .02: TDD isn't the only right approach to a problem but it certainly
brings a lot of positives to the table. I haven't grokked all the
arguments, etc yet in those articles though.

cheers,
Nimret

[Ross Bleakney [e-mail] [seajug]]

I think the articles are a reaction to frameworks or design patterns that go out of their way to make it easy to test the code, but harder to understand what is going on. There are always trade-offs. But if all you are gaining is a little bit of speed in running automated tests (e. g. by avoiding database calls) then maybe it isn't worth it.

Personally, I find TDD (as well as tests that are undoubtedly unit tests, as opposed to automated integrated tests) most helpful with utility type code. This is code that if it is generic enough, will be found in a third party package somewhere. For example, if I find that I suddenly have a need to extract a string between two strings repeatedly, then I'll write that as an independent util method and I'll write a whole bunch of tests to support it. Of course, in that case, I'll just StringUtils (but you get the idea).

I also find unit tests quite helpful for understanding the code, and helping me build a project, step by step. For example, I might need to access an internal API within the code. So, the first thing I do is look for a "unit test" that calls the API and parses the results. It is more like demo code, rather than a true unit test. But running this automatically still helps. If the server that support the API is down, the failed unit test will tell me immediately, instead of having to wade through a bunch of code to see where the problem is.

I think one of the big assumptions about unit testing is that folks need to support new unit tests if the code changes and breaks the test. Obviously if the code is working the same way and you changed the little util class, then you have a problem on your hands. But quite often, you've created a shortcut around the situation, and the old unit tests simply don't apply. In that case, I would just throw them away, and come up with new ones, as appropriate (and quite often, the appropriate thing is to rely on much higher level tests). A good example of this might be if Java code used to make a very generic SQL call, then parse the results. The unit tests might test the parsing (or even the SQL call). But if a new stored procedure is written to get exactly what the Java code ultimately wants, then I would throw away the unit tests for the parsing. Now any testing is bound to be at a higher level, which as the articles suggest, is not necessarily a bad thing.

Thanks,
Ross

To: seajug-***@public.gmane.org
From: seajug-***@public.gmane.org
Date: Wed, 20 Aug 2014 13:34:32 -0700
Subject: Re: [seajug] TDD is dead...


























On Wed, Aug 20, 2014 at 12:47 PM, Jason Osgood zappini-***@public.gmane.org [seajug] <seajug-***@public.gmane.org> wrote:









Also, factor in the Railed by Ruby (dynamic programming language) perspective: comprehensive testing mitigates not using a real compiler.

"comprehensive" is the keyword there. If you don't have that right then your customers will be doing your QA when they get runtime errors :)that's assuming that companies have a well fleshed out unit/integration/functional test strategy and implementation which is in lockstep with feature implementation/requirements.
Lastly, I worked thru the TDD book. Strategy works as advertised. It’d might even work in the real world, if I ever work on something I already knew pretty well. But that’s never been the case. I’m always making things up as I go.


from my experience the value in TDD is directly proportional to the crispness of the requirements; even for the unknown stuff.
If TDD does nothing more than make devs consider the client code perspective during design, then it’s a win in my score book.


my .02: TDD isn't the only right approach to a problem but it certainly brings a lot of positives to the table. I haven't grokked all the arguments, etc yet in those articles though.
cheers,
Nimret