Print statements in unit tests

[RjOllos]

When I put `print` statements inside a unit test case I don't see any output in the console window. Any idea of why this might be?

I know it's not the most elegant way to debug, but sometimes the quickest way to get some info about a variable when debugging some Trac code, particularly since I'm still a beginning with python and not proficient with pdb and other tools that exist.

Thank you for your time,

- Ryan 

[Ethan Jucovy]

On Mon, Nov 19, 2012 at 1:07 AM, RjOllos <ry...@physiosonics.com> wrote:

When I put `print` statements inside a unit test case I don't see any output in the console window. Any idea of why this might be?

I know it's not the most elegant way to debug, but sometimes the quickest way to get some info about a variable when debugging some Trac code, particularly since I'm still a beginning with python and not proficient with pdb and other tools that exist.

Python testrunners like to swallow output from print statements, unfortunately.  Some also like to swallow pdb breakpoints.

I believe the Right Way to do this sort of debugging in tests is to use Python's logging framework.  But I'm always too lazy to look this up.  I usually end up doing ``logfile = open("/tmp/test.log", "a"); print >> logfile, "log message"; logfile.close();`` instead, and `tail -f /tmp/test.log` in another console window while I run my tests.

-Ethan

[Ethan Jucovy]

Oh, the other Lazy Approach I sometimes use is to just bypass the testrunner and execute my test file directly with `python path/to/my/tests.py`.  Depending on how the tests are written, this may or may not work.  For example most of Trac core's tests do run properly this way -- `python trac/tests/perm.py` etc works fine.

When it does work it's really convenient -- you're in a normal Python environment, you can print and pdb all you want, and also you can be really selective about which tests you're running.  (When I'm doing this I will often just comment out lines in the `suite()` definition so that I'm only executing the test I'm debugging at the moment.  Then I just need to remember to restore the full test suite before I do a final-real-test-run and commit.)

I'm sure there are Right Ways to do these things too but as a bad habit I highly recommend this method.  :-)

-Ethan

[Olemis Lang]

On 11/19/12, RjOllos <ry...@physiosonics.com> wrote:
> When I put `print` statements inside a unit test case I don't see any
> output in the console window. Any idea of why this might be?
>

Maybe stdout is redirect somewhere else , or your messages are
entangled in the tons of prose output by unittest runners , ... You
should use the log in functional tests and anywhere you have access to
an environment (<= indeed if that's the case those will be functional
tests already ;) .

> I know it's not the most elegant way to debug, but sometimes the quickest
> way to get some info about a variable when debugging some Trac code,
> particularly since I'm still a beginning with python and not proficient
> with pdb and other tools that exist.
>

If you provide further details the response might be more accurate .
;)

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

[Ryan Ollos]

On Sun, Nov 18, 2012 at 10:53 PM, Olemis Lang <ole...@gmail.com> wrote:

Maybe stdout is redirect somewhere else

That seems likely, andI was hoping someone would know how to deal with this since I'm just running the standard Trac unit tests.

 

or your messages are

entangled in the tons of prose output by unittest runners , ...

No, there is no output at all from print statements.

 

You
should use the log in functional tests and anywhere you have access to
an environment (<= indeed if that's the case those will be functional
tests already ;) .

I don't follow. How does this help me debug a unit test?

 

If you provide further details the response might be more accurate .
;)

What further details would you like? I'm not asking for help with debugging a particular unit test, I'm just asking if anyone else has had success directing print statements to the console when running unit tests.

I haven't had a chance to try Ethan's suggestions yet, but those look promising.

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I do add print statements to unit test quite often to speed-up debugging
recently. So I can confirm that they do work. In fact I've found them to
work most of the time, but not always. Still I've discovered other ways
to get to data from places, where print statements don't work.

Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlCsDOsACgkQ31DJeiZFuHcb6wCfbDhin6b8nLZH6itGfb9Fkvm6
F+EAn017rNdP3S0Xl7aAWxcNTki7+wLn
=tdTA
-----END PGP SIGNATURE-----

[Ryan Ollos]

On Tue, Nov 20, 2012 at 2:11 PM, Ryan Ollos <rjo...@gmail.com> wrote:

[...] 

You
should use the log in functional tests and anywhere you have access to
an environment (<= indeed if that's the case those will be functional
tests already ;) .

I don't follow. How does this help me debug a unit test?

Nevermind my comment. I see now that you were just making a side comment about functional tests, which I misread as somehow being a comment about unit tests, but in a way that I couldn't understand. 

[Olemis Lang]

That suggestion is similar to Ethan's , yes . They both consist in
using Python logging infrastructure , that way you could either send
msgs to stdout or a file and then «tail -f» it . If you are lazy (jftr
*LIKE ME* :P ) and one environment is handy inside test method body ,
just reuse it and «tail -f» ./log/trac.log file of the disposable
environment used for testing purposes.

[Ryan Ollos]

On Tue, Nov 20, 2012 at 3:06 PM, Steffen Hoffmann <hof...@web.de> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[...]

I do add print statements to unit test quite often to speed-up debugging
recently. So I can confirm that they do work. In fact I've found them to
work most of the time, but not always. Still I've discovered other ways
to get to data from places, where print statements don't work.

One of the comments in your code suggests to me that you run unit tests like: `PYTHONPATH=. python path/to/my/tests.py`. Is that always or nearly always true? I've been running them using `PYTHONPATH=. python test`, so I'll have to try both ways next time around now that I've seen Ethan's comment.

[osimons]

"PYTHONPATH=. python setup.py test" you mean. Sure, as long as there is an entry for tests defined in setup.py. To avoid running the full suite each time, you can of course make each test file runnable. Either call it as suggested above, or using python -m mymodule.tests.mytest to execute the module by name.

If you want to inspect what happens in a test, then spend the half hour necessary to learn basic pdb. It is not scary at all, and most of the time you can just consider it an interactive interpreter.

HOWTO: Instead of littering with "print" just add a "import pdb; pdb.set_trace()" line to break into the interpreter on execution. At pdb prompt you can print whatever you like, change variables, run statements to check and whatever - using print statements or whatever you like. Enter 'next' (or 'n') to execute next statement. Enter 'continue' (or just 'c') to exit debugging and continue running the code. Anyway, plenty of simple tutorials to google.

pdb works great for tests running in single thread and process - ie. don't use it for code being run by a web server...

:::simon

[RjOllos]

On Wednesday, November 21, 2012 7:21:04 AM UTC-8, osimons wrote:

[...]

If you want to inspect what happens in a test, then spend the half hour necessary to learn basic pdb. It is not scary at all, and most of the time you can just consider it an interactive interpreter.

Yeah, you are right, it was quite easy to get ramped up on. In addition to the direct help you gave here, I found the Python docs page is very concise and clear (not surprised, of course!)

http://docs.python.org/2/library/pdb.html