[TIP] Going From Untested Perl to Tested Python

Noah Gift noah.gift at gmail.com
Mon Feb 2 03:11:49 PST 2009

On Mon, Feb 2, 2009 at 4:27 PM, Noah Gift <noah.gift at gmail.com> wrote:
> On Mon, Feb 2, 2009 at 4:05 PM, Paul Hildebrandt
> <Paul.Hildebrandt at disneyanimation.com> wrote:
>> Kumar McMillan wrote:
>>> On Sun, Feb 1, 2009 at 5:16 PM, Noah Gift <noah.gift at gmail.com> wrote:
>>>> Hi,
>>>> I am starting to convert a rather large code base from untested Perl
>>>> to tested Python.  One idea I had was to write tests in Python, that
>>>> tests the Perl code.  Once I have the core functionality worked out,
>>>> the next step is to rewrite it in Python, and finish off unit testing.
>>>>  Has anyone else done something like this, and if so do you have
>>>> recommendations?
>>> Hi Noah.
>>> I did exactly this once for a set of command line scripts (migrated
>>> untested perl scripts to python scripts, implementing all new scripts
>>> in python-land).  I attempted to create tests for all the legacy
>>> scripts so I could simply swap them out with a python one and have the
>>> tests still pass.  I spent a lot of time doing crazy DB setup and file
>>> layout setup so that the tests could execute the perl scripts in a
>>> subprocess.  I would not recommend this approach for a few reasons.
>>> First, it is a huge pain to go through all the setup needed for such a
>>> high level "black box" testing approach.  Secondly, the legacy script
>>> tests were hard to maintain since they relied so much on a database.
>>> Yes, they did need to be maintained because the perl was never fully
>>> ported to Python (there was just too much).
>>> I would suggest an approach like this.  Assume the legacy perl code
>>> just works and don't touch it.  Make a plan for how much you can
>>> realistically migrate to Python and begin all new work in Python.
>>> Start the new Python project with tests and don't worry about testing
>>> the legacy Perl code.  If you find yourself in a situation where you
>>> need to fix a bug in the legacy perl code consider rewriting it in
>>> Python first and if that's not feasible then maybe that's a good
>>> enough excuse to create tests for perl code before you fix the bug.
>>> Otherwise, in my experience, it wasn't worth the effort to retrofit
>>> the perl code with tests.
>>> YMMV of course :)
>>> Kumar
>> +1 that is how we've done the same thing.
> Good to hear to different takes on it.  Of course Paul, working in
> film like I do, has a particularly good grasp of the problem I am
> facing :)  I suppose there is something to be said for not wasting
> resources on Perl code, when you can just rewrite it in Python.  As
> Ben mentioned, it is probably going to be frustrating because the code
> is often not testable anyway.

One last question.  How did the people that responded feel about the
"perl" module:  http://search.cpan.org/~gaas/pyperl-1.0/perlmodule.pod

I have noticed there is quite a bit of code that uses this as a
"bridge" to connect to legacy code.  Hooking up new "clean" python
code to old untested perl code, seems like a violation of all that is
holy, akin to breeding an ape with a human:

>>>> For the Python code that is untested I am using Pythoscope, which is
>>>> quite nice so far.
>>>> --
>>>> Cheers,
>>>> Noah
>>>> _______________________________________________
>>>> testing-in-python mailing list
>>>> testing-in-python at lists.idyll.org
>>>> http://lists.idyll.org/listinfo/testing-in-python
>>> _______________________________________________
>>> testing-in-python mailing list
>>> testing-in-python at lists.idyll.org
>>> http://lists.idyll.org/listinfo/testing-in-python
> --
> Cheers,
> Noah



More information about the testing-in-python mailing list