ok-client icon indicating copy to clipboard operation
ok-client copied to clipboard

Test for printed vs. returned values

Open peterasujan opened this issue 10 years ago • 14 comments

(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.

peterasujan avatar Feb 09 '16 05:02 peterasujan

You can test with doctests by doing something like

>>> r = square(2)  # prints nothing
>>> r  # test return value
4

knrafto avatar Feb 09 '16 05:02 knrafto

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)?

peterasujan avatar Feb 09 '16 06:02 peterasujan

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?

knrafto avatar Feb 09 '16 06:02 knrafto

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.

Sumukh avatar Feb 09 '16 06:02 Sumukh

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?

peterasujan avatar Feb 09 '16 06:02 peterasujan

Based on: http://stackoverflow.com/questions/1024411/can-python-doctest-ignore-some-output-lines

>>> r = square(4)  # doctest:+ELLIPSIS
...
>>> r
9

knrafto avatar Feb 09 '16 06:02 knrafto

Oooh perfect! Didn't realize it was just directly using the Python doctest package. Thanks for the help guys!

peterasujan avatar Feb 09 '16 06:02 peterasujan

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

Sumukh avatar Feb 09 '16 06:02 Sumukh

I just did a quick test of # doctest:+ELLIPSIS and it doesn't appear to work.

jathak avatar Feb 09 '16 07:02 jathak

Sorry, I thought it used the doctest module. My bad!

knrafto avatar Feb 09 '16 07:02 knrafto

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!

peterasujan avatar Feb 09 '16 07:02 peterasujan

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

PNHilfinger avatar Feb 09 '16 22:02 PNHilfinger

You can have students use the print("DEBUG:", ...) feature to allow them to print without it interfering with the ok tests.

kavigupta avatar Nov 25 '19 02:11 kavigupta

But we probably should have a wildcard of some kind

kavigupta avatar Nov 25 '19 02:11 kavigupta