[Biopython-dev] run_tests.py rewrite

[Michiel de Hoon]

Maybe it was a mistake to call this a rewrite ... basically all I'm doing is making some changes in run_tests.py so that it will distinguish between unittest-style tests and print-and-compare tests, and cleaning up some code while I'm at it. This will allow us to remove the trivial output files for the unittest-style tests, which were a real annoyance because they had to be updated whenever a new test was added to an existing test script. And since the output files did not contain any real information, people tended to forget that. Maybe nose can do the same as unittest, but unittest comes with Python and nose does not, so as long as unittest does the job, I see no reason to change to nose.

--Michiel.


--- On Tue, 2/3/09, Giovanni Marco Dall'Olio <dalloliogm at gmail.com> wrote:

> From: Giovanni Marco Dall'Olio <dalloliogm at gmail.com>
> Subject: Re: [Biopython-dev] run_tests.py rewrite
> To: "Peter" <biopython at maubp.freeserve.co.uk>
> Cc: biopython-dev at biopython.org
> Date: Tuesday, February 3, 2009, 6:46 AM
> ufff I am sorry but the more I think about it, the more it
> seems a
> nonsense to me..
> Why are you writing a new test-discovery framework for
> biopython, when
> there are many already available that work fine and better?
> Isn't it a waste of time, really? I am not criticizing
> you - but
> speaking from a purely technical point of view, I really
> don't
> understand.
> 
> If you are worried that using nose will add a new
> prerequisite to
> biopython (which is not true, by the way), you can easily
> include the
> nose executable within the test dir, as I think many other
> projects
> already do;
> 
> Honestly, I have the feeling that you didn't even had a
> look at all
> the links I posted in the old discussion on nose, neither
> you have
> tried it, and that's so bad. You didn't discuss
> about the pros or cons
> of nose, you just kept saying 'it would add a
> prerequisite to
> biopython' (which is not true, again), and started
> writing your own
> new test discovery framework.
> With nose, you could have a good testing infrastructure and
> take
> advantage of things like global fixtures, automatic
> formatting of the
> output, integration with profilers, and a lot of things
> more.
> 
> It seems a nonsense to me, because with biopython you
> provide source
> code that you make available to all the bioinformaticians,
> with the
> idea that reuse of the code is good; but then, you
> don't want to use
> the code written by someone else.
> I have seen many bioinformatician telling me that they
> don't use
> biopython because they don't have the time to study it
> and they don't
> know how it works. I really believe that this is terrible,
> making the
> whole bioinformatics field a mess.
> 
> Cheers :)
> 
> On Tue, Feb 3, 2009 at 11:35 AM, Peter
> <biopython at maubp.freeserve.co.uk> wrote:
> >>> I think Michiel has only switched over
> test_Cluster.py thus far.  The
> >>> doctests are currently run via
> test_docstrings.py which is still a
> >>> print-and-compare test for now.
> >>
> >> ah! I see.
> >
> > I was wrong - as Michiel clarified in a later comment,
> run_tests.py
> > should have been finding all the unittest based tests
> (but right now
> > it isn't).  As in my earlier email, some of our
> unittest cases use a
> > prefix of "t" and others use
> "test" meaning only some of the unittest
> > test cases are currently being detected.  One this is
> fixed, then
> > test_docstring should work too.
> >
> >>> Could you show us the error with test_CAPS.py
> please, with details of
> >>> your setup.  This test is working for me.
> >>
> >> sorry.. it works fine if I run it from within the
> Tests dir.
> >
> > Good.  Thanks.
> >
> > Peter
> >
> 
> 
> 
> -- 
> 
> My blog on bioinformatics (now in English):
> http://bioinfoblog.it
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biopython-dev