[TIP] best strategy for retrofitting code with unit tests
Nate Lowrie
solodex2151 at gmail.com
Mon Mar 5 15:00:44 PST 2007
On 3/5/07, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> Nate Lowrie wrote:
> > Ok, I have done a couple of small - medium sized projects through a
> > TDD cycle and have been successful at it. Now, we are trying to
> > retrofit a large framework (Dabo) with unit tests. It's a 3 tier
> > framework with an agnostic db layer, business object/logic layer, and
> > a UI layer that currently wraps WxPython.
> >
> > What is the best strategy for this? Should we just adopt a TDD for
> > all new code and do a refactor/red/green cycle on the existing code as
> > the new code comes in? Should we unit test the business layer only
> > and resign to acceptance testing on the other 2?
> >
>
> NB I've not had to *do* this, so my suggestion is theoretical only.
>
> I would add acceptance tests for the higher levels as soon as you can.
Any suggestions for acceptance testing the UI layer? It is a wrapper
over wx that makes th UI more pythonic. It also constitutes about 60%
of the code base. I remember seeing something about pywinauto but
wasn't quite sure if that was for window forms or another toolkit.
>
> I would add unit tests for code as you refactor, but apply this to all
> the layers. That should eventually get you pretty good coverage.
I would agree
>
> It is more a difficulty if you just want to retrofit tests without
> actually needing to touch a lot of the other code - but at least this
> approach will get you off the ground and you can review it.
There were no tests written before hand. I am truly amazed that the
code is as refactored as it is. I can refactor the code at will, but
I am concerned that I will break something without the unit test
coverage.
>
> Fuzzyman
> http://www.voidspace.org.uk/python/articles.shtml
>
More information about the testing-in-python
mailing list