Re: Re: Good Test Driven Development links

Hi David,

I assume you meant me and the discussion in the other thread.

To me the biggest negative side-effect is the difficulty in testing. I
believe this is a real issue. It is not just that there is no real way to
test if the solution works, only that it works most of the time in the
situations that we can think of. It is that the code is potentially brittle
and fragile.

I am a firm believer in refactoring. Code is a living, breathing thing. It
needs to grow and it needs to change in order to be able to adapt to a
changing world. The code must be maintainable and the cost of maintenance
must be kept as low as possible. It must be possible to add new features
and modify existing ones without too much pain. This is where refactoring
comes in - allowing us to make code pliable, to separate responsibilities,
to keep changes localized to the areas that need changing.

Without the safety net of tests (and I don't mean integrated tests as
integrated
tests are a scam<http://blog.thecodewhisperer.com/2010/10/16/integrated-tests-are-a-scam/>
-
I mean that in the way JB means it), then refactoring is just code and
pray. So for me, the actual and real negative side effect of hard-to-test
code is that it is dangerous to refactor, and therefore difficult to
maintain.

Another actual negative side-effect is that this company has been forced
into standardizing defects - in other words defects are a built in part of
the process. I don't want to produce code expecting defects. I want to
expect no defects and to be disappointed when there are defects.

A third actual negative side-effect is that the code is not reusable. If I
can't use this code as a client in a test then I have no chance of using it
in any other scenario apart from the current one. It is bolted in too tight.

And finally, I can't make use of the opportunities presented by OO
programming. I find the inability to define responsibilities via interfaces
to be a big negative. The design tends towards a big ball of mud where
there are no clear boundaries and everything may or may not depend on
everything else.

And as it stands, every time an (expected) defect surfaces, all we can do
is code and pray.

Regards
David


On 28 June 2013 07:51, Parsons, David <[email protected]> wrote:

> **
>
>
> David,
>
> I'm interested to read this discussion, but what I'm missing is an
> explanation of what kinds of problems are being caused by the current
> architecture. Presumably the remainder of the team will only see the value
> of a new approach if there are evident issues with the current one. Not
> liking what the code looks like is not in itself a problem. Do you have
> some illuminating examples of where negative side-effects are arising? Is
> it just that it is hard to test? Or is there more to it than that?
>
> Dave
>
> **************************************************************
> Dr. David Parsons
> Associate Professor of Information Technology
> School of Engineering and Advanced Technology
> Massey University
> Auckland, New Zealand
>
> Ph: 0064 (0)9 414 0800 ext. 43135
> Email: [email protected]
> Web: http://www.massey.ac.nz/~dpparson/
> ***************************************************************
>
> [Non-text portions of this message have been removed]
>
>  
>


[Non-text portions of this message have been removed]



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

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/