[IPython-user] Interactive testing with ipython [Was: Question about ipython.el (autoreload)]

[Alexander Schmolck]

bruno <bruno.chazelas@ias.u-psud.fr> writes:

[about using the autoreload hack to make rerun tests without having to restart
ipython after each code change]

> This must be a fine package, but my need for ipython restarts seems to 
> be triggered exactly by the pitfalls of this package : I am using 
> classes  

It's possible to handle the most common cases with classes by mutating the
existing class. This will affect all running instances of this class. 

Of course this may not do what you want, e.g. because attributes no longer
make sense. OO languages with interactive development support from the ground
up can deal with this, e.g. in common lisp you can arrange that if you
redefine your Point class to store coordinates in polar rather than cartesian,
all running instances will automatically have their attributes (slots in
lisp-speak) converted to polar.

<http://www.lisp.org/HyperSpec/Body/stagenfun_upd_efined-class.html>

It's unlikely to ever work that well in python, which wasn't really designed
with full-blown interactive development in mind, but that doesn't mean one
shouldn't try to get closer ... :)

> and nested module dependencies. I 'll give it a try but I think I will still
> need to retart regularly the ipython.

Most likely. Handling non-trivial module dependencies and imports properly is
also likely to require some parsing or a custom import command (I tried this
once to get automatic and proper reloading and also versioning support, but I
never got to complete it).

However, since I find test-driven developing with plain unittest *really*
annoying (you write the test, it fails test-x you change your code, reload,
run the tests again and wait some time for all the tests before test-x again,
you have no idea why it fails and thus insert some print statements for
debugging etc), I've recently resurfaced some hack for nice, interactive
test-driven development with ipython and debugger support. 

Basically you just add the following lines add the end of a test module
developed with unittest:

    # test_foo.py
    ...
    if __name__ == '__main__':
        from awmstest import main, setPermeable, setRotating
        setRotating();  # start again at the last failed test
        setPermeable(); # pass exceptions thru, 
        main()          # run all tests found in his module

do ``pdb on`` and ``run test_foo.py`` -- and unittest suddenly remembers where
the last test failed and runs it again -- also, with ``setPermeable(True)``,
you end up in the debugger on a testfailure, and emacs opens the corresponding
file/line if you're using ipython.el so you can easily find out what went
wrong (no ``print "DEBUG..."`` statements), using ``setPermeable(False)``
gives normal unittest behavior (errors are just logged).

The code appears to work, but isn't properly tested or release quality right
now (it's reasonably short, though, < 200LOC) -- but your post got me thinking
that it might be nice to bundle such functionality as a magic function for
ipython (e.g.``runtests test_foo.py``?). I think for long running and
complicated test suites (esp. for numerical stuff where failures can profit
from some more fancy inspection then prints) this could be real development
time saver. Would there be any interest in adapting this for
ipython-inclusion?


'as