Re: Suggestion, advice on TDD adoption

"Adam Sroka [email protected] [testdrivendevelopment]" <[email protected]> Wed, 6 Apr 2016 13:53:54 -0700
Newsgroups gmane.comp.programming.test-driven-development
Message-ID <CALaPUVdkUyzYiBZ2m=-iLBEkYs3dahVusc4aMjwnfxRxgeXdCQ@mail.gmail.com>
On Wed, Apr 6, 2016 at 1:40 PM, Avi Kessner [email protected]
[testdrivendevelopment] <[email protected]> wrote:

>
>
> I think the hardest part of starting with legacy code is that as novices
> you will write brittle tests, and that is likely to give you bad design as
> you redactor. It's really important that you go through the process of
> learning what good (non fragile, non brittle) tests look like and how to
> write them.
>

Keeping the tests informative (i.e. fail only for the right reason and do
so quickly) requires deliberate effort either way. It is mostly impossible
to write tests that aren’t brittle around code that is. That is why I
suggest strongly that you keep refactoring until you have a “good OO
design.” Defining that is a little bit complicated and probably belongs in
its own thread.

If you write brittle tests around brittle code and then say, “Okay, it’s
covered. Now we’re done,” then you either know less about design than you
need to or you are in denial (It could definitely also be both.)

The advantage of working with legacy code however is that you have better
> defined acceptance tests etc.
>

It depends how legacy your legacy code is. I have encountered systems where
the requirements were defined in a document no one had read and what the
code did was not what the document said. I have encountered other systems
where the only requirement was that the system keep doing whatever it was
that it did, and no current employee knew what that was.