pytest.print()

[The-Compiler]

Split off from #1600:

I like this! It'd also make it easier to add an uncaptured pytest.print(msg) for easy printf-style debugging (without having to use -s and being greeted by a firehose of output).

[nicoddemus]

print is a reserved word on Python 2, so we will have to find another one...

[The-Compiler]

Oh, good point. I'd say pytest.echo() then, like click.echo().

[nicoddemus]

Sounds good!

[RonnyPfannschmidt]

Imho feature creep

[The-Compiler]

I disagree - it's not just a feature I want (otherwise I'd just put a function in my testsuite's utils.py), it's something I see people ask for from time to time, and something which is quite useful for debugging in general I'd imagine.

Also, it's not like it'd be overwhelmingly complex - probably <10 lines, most likely <5 😉

[RonnyPfannschmidt]

As described here its a explicitly integration avoiding alternative to our print debugging while also being subpar for plugin ux stuff

[The-Compiler]

I don't understand what you're saying, sorry. Could you elaborate?

[RonnyPfannschmidt]

py.test has explicit print debug support and uses capturing to bind print output and test items

throwing in a print thing that explicitly decouples that again is contrary to the actual design which is supposed to leave the print/logging statements in

[codewarrior0]

Maybe the idea is to separate debug output between the code being tested and the test code itself. I can see this being done (almost trivially) as a fixture that provides an object with a "print" function, and attaches the collected output to the report for that particular test. Then that collected output can be written to terminal (etc) even if the normally captured output is not written (due to lack of -s/-rP). This can be done with something like a plugin report hook, right?

[RonnyPfannschmidt]

Correct

[vperron]

I'd say to me this feature would be really useful to have some echos during the fixtures execution. I don't care (and don't want) verbose output during the tests themselves, but some of my fixtures are complex, stateful and some output would be better than the -s I'm using as of now.

[nicoddemus]

Then that collected output can be written to terminal (etc) even if the normally captured output is not written (due to lack of -s/-rP).

So the collected output will always be written to the terminal, even if the test passes?

[RonnyPfannschmidt]

imho we shouldn't have a print, but rather a "ui" to interact with as a experiment

[nicoddemus]

imho we shouldn't have a print, but rather a "ui" to interact with as a experiment

Sorry, could you please clarify that? Perhaps a quick code example and sample output would help. 👍

[RonnyPfannschmidt]

@nicoddemus a print as conceived would very likely be console specific, and used as such,

in order to eventually disengage from the limited console as output i'd like to engage in trying at a higher level ux, where we can do things like report progress, log details to the users in a way that can be used from the simple console, rich vonsoles suchas pytest sugar and even a IDE/gui/web display of pytest runs

also i#d like to be able to record /log things in a way that we can do a py.test run and later replay its output

so the larger picture goal as quite some components, and i should write to the ml about it

[The-Compiler]

I don't see how that's related to this issue. You're always going to have some kind of text-based output (captured stdout, logs, whatever), which you'd want to see in some kind of console-equivalent in a IDE/GUI/webinterface/…. Having a pytest.echo() seems to fit in nicely with that, no?

[RonnyPfannschmidt]

@The-Compiler i for one dont think so, i>'d love to later on grow the ability to combine/intersparse and filter things like logs and output per tests while having other diagnostics not be part of it

to me the uses of the different "data" elements are inherently different

[The-Compiler]

And how would a debug pytest.echo() keep you from doing that?

[dsully]

+1 - it's really hard to debug pytest output (especially with say copious SQLAlchemy logging).

[nicoddemus]

Now that we have logging, I wonder if we can use cli_log together with an exclusive logger to attain this? For example, -o log_cli=true -o log_name=pytest would print only messages from the pytest logger, which users are free to use for their own debugging purposes? log_name is not implemented in pytest at the moment, but it has been suggested before.

If this seams feasible, I can envision we having a --pytest-log option as shortcut for the above or something similar.

Just an idea.

[The-Compiler]

Hmm, that'd mean it wouldn't print by default though, right? I think the main motivation for this (at least from me, and judging from questions in IRC and other places, not only me) is to have an easy straightforward way to print something for debugging without having to set up things.

[defnngj]

Someone has made it happen.
https://github.com/pytest-dev/pytest-print

[Zac-HD]

Closing this as provided by the pytest-print plugin 😄