[IPython-user] ls and cat commands fail

Brian Granger ellisonbg.net@gmail....
Wed Jun 4 10:21:38 CDT 2008


I think getting the testing system in place is going to be relatively
easy.  Here is how we are doing it in ipython1:

1) The code is organized into subpackages:

ipython1.kernel
ipython1.core
ipython1.config

Each of these has its own tests subpackage:

ipython1.kernel.tests
ipython1.core.tests
ipython1.config.tests

Each of these directories has files names like test_foo.py.  These
files in turn have 1) unittests and 2) other tests that Nose will pick
up.

2) doctests are included in docstrings

3) Nose is used to run the tests

4) Dev's just have to write tests.  BUT, they have to make sure that
if the code being tested has dependencies other than python itself
(like twisted), that you test for the deps and don't run the tests if
the deps are not present.

There are a few things that are missing in this picture that we can fill in:

1) It would be nice to be able to tag tests and run only subsets of
tests that have those tags.  This would provide a nice easy way of
handling dependencies in tests.

2) It would be nice to be able to have doctests with ipython syntax.

Once I start the ipython1 merge all this will come into trunk.

Cheers,

Brian

On Wed, Jun 4, 2008 at 9:10 AM, Fernando Perez <fperez.net@gmail.com> wrote:
> On Wed, Jun 4, 2008 at 7:56 AM, Johann Cohen-Tanugi
> <cohen@slac.stanford.edu> wrote:
>> 1) I totally agree
>> 2) I volunteer for testing the testing system
>> 3) I would like to solve my profile problem :(
>>
>> ;) cheers,
>> Johann
>
>
> 1, 2) Thanks!
> 3) We will, I promise.  Not today (gotta run and I have meetings all
> day) but as soon as I can.
>
> Cheers,
>
> f
>
>> Fernando Perez wrote:
>>>
>>> On Wed, Jun 4, 2008 at 7:17 AM, Ville M. Vainio <vivainio@gmail.com>
>>> wrote:
>>>
>>>
>>>>
>>>> Of course everything should be of high quality, but the limited amount
>>>> of testing received by rarely used components hampers this quite a
>>>> bit.
>>>>
>>>
>>> No, they receive a limited amount of testing because we don't have
>>> automatic testing in place.  'release early, release often' does not
>>> mean 'release broken code all the time'.   Sage, for example, releases
>>> every two-four weeks, but without ONE line of code that hasn't gone
>>> through thorough review, voting and doctest checking.
>>>
>>> So no: I am *fundamentally* opposed to the notion that we release
>>> broken code and hope users come back with the pieces to us.  Now that
>>> I've flushed my long backlog of messages that had fallen through the
>>> cracks and that we seem to be in reasonable shape with the bzr
>>> transition, I'll stop making small fixes in the 'hope it works from a
>>> few manual checks' mode (which I did last night and managed to commit
>>> a huge blunder with for a few minutes).
>>>
>>> My next immediate priority will be to put in place a proper testing
>>> system.  We have all the pieces in place, it's just a matter of
>>> assembling them, and it is critically needed so we can land the ip1
>>> code, that does have full testing.
>>>
>>> It won't happen right away, because after this recent ipython marathon
>>> I have to pay attention to some local work issues and I have a trip
>>> all next week, but I'll scavenge every moment I can to try and make it
>>> happen.
>>>
>>> Regards,
>>>
>>> f
>>> _______________________________________________
>>> IPython-user mailing list
>>> IPython-user@scipy.org
>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>>>
>>
> _______________________________________________
> IPython-user mailing list
> IPython-user@scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>


More information about the IPython-user mailing list