Hi Vasily,
On Sun, Jun 12, 2016 at 3:24 PM Vasily Kuznetsov wrote:
>
> It took a while but today I finally finished the README and I think it's
> sort of ready for someone to take a look:
> https://github.com/kvas-it/pytest-console-scripts. The tests fail for
> Python 2 on Travis for reasons I d
Hi Bruno,
It took a while but today I finally finished the README and I think it's
sort of ready for someone to take a look:
https://github.com/kvas-it/pytest-console-scripts. The tests fail for
Python 2 on Travis for reasons I didn't quite understand yet and the
features, as well as documentation
On Thu, Apr 28, 2016 at 5:45 PM Vasily Kuznetsov wrote:
> Yeah, this is exactly what I had in mind (articulated in more detail than
> I had in mind :).
> I think I'll put some code together when I have a bit of time and then we
> can see.
>
Nice! Make sure to use cookiecutter-pytest-plugin[1] to
Yeah, this is exactly what I had in mind (articulated in more detail than I
had in mind :).
I think I'll put some code together when I have a bit of time and then we
can see.
Thank you,
Vasily
On Thu, Apr 28, 2016 at 6:35 PM Bruno Oliveira wrote:
> On Thu, Apr 28, 2016 at 1:20 PM Vasily Kuznets
On Thu, Apr 28, 2016 at 1:20 PM Vasily Kuznetsov wrote:
> Yes, exactly, I want to do both (in-process and subprocess). So while I'm
> hacking on the new features I'd run in-process for speed and then I'd use
> something like tox to run proper subprocess tests in different
> environments. And thos
Yes, exactly, I want to do both (in-process and subprocess). So while I'm
hacking on the new features I'd run in-process for speed and then I'd use
something like tox to run proper subprocess tests in different
environments. And those would be the same tests, I'd just change some
configuration sett
On Thu, Apr 28, 2016 at 4:21 PM, Vasily Kuznetsov wrote:
>
> pytest-cram and cram in general looks quite neat, but I guess it doesn't
> allow the second approach of running everything in the same python process,
> which is an important feature for example for doing TDD.
>
That reminds me of tha
Well, I was just thinking that all scripts that are exposed using
console_scripts entry point from setup.py could be tested in a similar way
to how the standard script wrappers run this code. We would need to mock
some things and do clean up afterwards and it would work for most simple
use cases. S
Thanks for the pointers, Florian.
The testdir fixture from pytest is pretty much what I was thinking about.
So if we could have a more generic version of it, wouldn't it be cool?
pytest-cram and cram in general looks quite neat, but I guess it doesn't
allow the second approach of running everythi
On Thu, Apr 28, 2016 at 3:11 PM, Florian Bruhin wrote:
> FWIW there's pytest-cram which has a totally different approach, but
> seemed quite interesting:
>
> https://github.com/tbekolay/pytest-cram
> https://bitheap.org/cram/
>
Cram is indeed nice but it doesn't really work on Windows so I even
click for example ships libraries for testing commandlines made with it
my current impression is that
typically command line applications are opinionated enough,
that deep integration is very custom and shallow integration is so shallow
a plugin would either be application specific or so small th
* Vasily Kuznetsov [2016-04-28 11:55:48 +]:
> I was recently writing some tests for a bunch of console scripts. I ended
> up having a parametrised function that can run a script for real (using
> subprocess.run) or can import its main function, mock the environment and
> execute it in the same
Hi!
I was recently writing some tests for a bunch of console scripts. I ended
up having a parametrised function that can run a script for real (using
subprocess.run) or can import its main function, mock the environment and
execute it in the same process (this is much faster).
I've done similar t
13 matches
Mail list logo
