Test for printed vs. returned values
(currently developing labs for DS8) The example here seems to suggest that printing is indistinguishable from actual returned values. Is there a way to test specifically for one or the other? If not, that could be a useful feature.
You can test with doctests by doing something like
>>> r = square(2) # prints nothing
>>> r # test return value
4
Thanks for the quick response!
That certainly works for testing the return value, but what if square printed a bunch of stuff as well? Wouldn't I have to explicitly duplicate all of those lines below >>> r = square(2)?
If square printed a bunch of stuff it would fail the r = square(2) case, because it expects zero lines of output. I don't think I understand your question - what lines would you need to duplicate?
Yes. If you had print statements you would have to include them like so:
>>> r = square(3) # prints things
Performing calculation of 3*3
The answer is 9
>>> r # test return value
9
The first prompt tests explicitly for printing and the second explicitly tests for a return value.
Right, but what if I don't really care about what's being printed? Like maybe it's a huge number of logging lines or something. Or a student adds their own print statements (for testing/debugging, or whatever) and I don't want the tests to check for this?
Based on: http://stackoverflow.com/questions/1024411/can-python-doctest-ignore-some-output-lines
>>> r = square(4) # doctest:+ELLIPSIS
...
>>> r
9
Oooh perfect! Didn't realize it was just directly using the Python doctest package. Thanks for the help guys!
I haven't tried # doctest:+ELLIPSIS - here's another approach in case that doesn't work:
In the past we have suppressed student output by binding our own function to print in the setup method
Depending on how your test is designed the setup code would either have print = lambda *args: None or studentmodule.print = lambda *args: None
I just did a quick test of # doctest:+ELLIPSIS and it doesn't appear to work.
Sorry, I thought it used the doctest module. My bad!
Yeah, I'm finding that the behavior of +ELLIPSIS (even outside of ok) is a little inconsistent... I'll try that other option, thanks guys!
Kyle Raftogianis [email protected] wrote:
Based on: http://stackoverflow.com/questions/1024411/can-python-doctest-ignore-some- output-lines
r = square(4) # doctest:+ELLIPSIS ... r 9
— Reply to this email directly or view it on GitHub.
That particular case does not work, since ... is interpreted as a line continuation. There are various kludges, such as
>>> print('foo'); r = square(4) # doctest:+ELLIPSIS
foo...
>>> r
or creating a doctest subclass. See also
http://stackoverflow.com/questions/5812833/can-i-have-an-ellipsis-at-the-beginning-of-the-line-in-a-python-doctest
PNH
You can have students use the print("DEBUG:", ...) feature to allow them to print without it interfering with the ok tests.
But we probably should have a wildcard of some kind