> [...]
> Testing at levels of abstraction above the unit is important, but
> Python's ‘unittest’ is not a good fit. You'll need a different tool.
>
> For behaviour testing, I recommend Behave, which lets you describe
> assertions in English and have them automatically tested
> https://pypi.python.
Göktuğ Kayaalp writes:
> On Fri, Nov 01, 2013 at 10:42:23AM +1100, Ben Finney wrote:
> > Keep the body of “if __name__ == '__main__':” to an absolute
> > minimum. Put all of the set-up and process-end functionality into
> > discrete functions with discrete purposes, clear return values, and
> > e
Thanks Ben and Tim for these great contributions!
Shouldn't suggestions like these be added to the argparse documentation in a
recipes section?
Best,
Wolfgang
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, Nov 01, 2013 at 10:42:23AM +1100, Ben Finney wrote:
> Göktuğ Kayaalp writes:
>
> > I'm using python to write command line apps from time to time. I
> > wonder *what is the conventional way to test-run these apps from
> > within the project itself, while developing, without installing*.
>
>
On 2013-10-31 22:12, Göktuğ Kayaalp wrote:
> My usual practise is to have two entry points to the program as
> executable scripts.
When I create stand-alone command-line scripts that take arguments,
usually they're akin to version-control tools, so I have the form
scriptname.py [--global-opts]
Göktuğ Kayaalp writes:
> I'm using python to write command line apps from time to time. I
> wonder *what is the conventional way to test-run these apps from
> within the project itself, while developing, without installing*.
As with making any application testable: Make small functions that do
o
Hi all,
I'm using python to write command line apps from time to time. I wonder
*what is the conventional way to test-run these apps from within the
project itself, while developing, without installing*.
My usual practise is to have two entry points to the program as
executable scripts. I usuall
