headers
Ben Finney | 1 May 2011 02:46
Picon

Re: Announce: Automated Testing on Macintosh (PyATOM) 0.9 released

James Tatum <jtatum <at> gmail.com> writes:

> The PyATOM team is proud to announce the initial release of PyATOM.
>
> About PyATOM:
>
> Short for Automated Testing on Macintosh

Oof. I strongly recommend a rename: Atom is already well established in
programming as the name of a standard syndication and publishing format
<URL:https://secure.wikimedia.org/wikipedia/en/wiki/Atom_%28standard%29>.

The name “PyATOM” connotes “an Atom library for Python”, which this
is not.

--

-- 
 \     “When I was a kid I used to pray every night for a new bicycle. |
  `\    Then I realised that the Lord doesn't work that way so I stole |
_o__)                   one and asked Him to forgive me.” —Emo Philips |
Ben Finney

_______________________________________________
testing-in-python mailing list
testing-in-python <at> lists.idyll.org
http://lists.idyll.org/listinfo/testing-in-python
Permalink | Reply | 1 comment |
headers
Olemis Lang | 3 May 2011 14:48
Picon
Gravatar

Re: Announce: Automated Testing on Macintosh (PyATOM) 0.9 released

On Sat, Apr 30, 2011 at 7:46 PM, Ben Finney <ben+python <at> benfinney.id.au> wrote:
> James Tatum <jtatum <at> gmail.com> writes:
>
>> The PyATOM team is proud to announce the initial release of PyATOM.
>>
>> About PyATOM:
>>
>> Short for Automated Testing on Macintosh
>

Good to know there are FOSS pythonic libraries for this ... AWESOME !!!
keep up the good work !

> Oof. I strongly recommend a rename: Atom is already well established in
> programming as the name of a standard syndication and publishing format
> <URL:https://secure.wikimedia.org/wikipedia/en/wiki/Atom_%28standard%29>.
>
> The name “PyATOM” connotes “an Atom library for Python”, which this
> is not.
>

+1 . just by performing a quick search you'll realize that name is
already taken in PyPI , and is mentioned everywhere . so it clashes
with another existing Atom lib ...

:(

--

-- 
Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rustom Mody | 6 May 2011 04:11
Picon

secondary testing tools

For running a battery of tests (in good-ol C projects), the Makefile
is often used.

What is the recommended tool for orchestrating testing in python?

Is scons suitable for this? Or do folks just stay within nose,
unittest etc and not use a separate tool?
Permalink | Reply | 9 comments |
headers
vanderson.mota@gmail.com | 6 May 2011 04:18
Picon
Gravatar

Re: secondary testing tools

a normal python script?

2011/5/5 Rustom Mody <rustompmody <at> gmail.com>:
> For running a battery of tests (in good-ol C projects), the Makefile
> is often used.
>
> What is the recommended tool for orchestrating testing in python?
>
> Is scons suitable for this? Or do folks just stay within nose,
> unittest etc and not use a separate tool?
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python <at> lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>

--

-- 
Vanderson Mota dos Santos
Permalink | Reply | 0 comments |
headers
Jorge Vargas | 6 May 2011 05:43
Picon

Re: secondary testing tools

On Thu, May 5, 2011 at 10:11 PM, Rustom Mody <rustompmody <at> gmail.com> wrote:

For running a battery of tests (in good-ol C projects), the Makefile
is often used.

What is the recommended tool for orchestrating testing in python?

Is scons suitable for this? Or do folks just stay within nose,
unittest etc and not use a separate tool?

Mostly that. 

However they are plenty of Make/Rake replaments out there which are kind of ok but not all the way there. Personally I'm writting my own.
_______________________________________________
testing-in-python mailing list
testing-in-python <at> lists.idyll.org
http://lists.idyll.org/listinfo/testing-in-python
Permalink | Reply | 0 comments |
headers
Jamu Kakar | 6 May 2011 12:09
Picon
Gravatar

Re: secondary testing tools

Hi Rustom,

On Fri, May 6, 2011 at 4:11 AM, Rustom Mody <rustompmody <at> gmail.com> wrote:
> For running a battery of tests (in good-ol C projects), the Makefile
> is often used.
>
> What is the recommended tool for orchestrating testing in python?
>
> Is scons suitable for this? Or do folks just stay within nose,
> unittest etc and not use a separate tool?

There are a number of ways to run unit tests in Python.  I like
Twisted's trial runner a lot and usually have a Makefile with a check
target, like:

check:
    trial $PROJECT

I like to have a Makefile because I include targets to clean *.pycs,
generate releases with setup.py, etc.  If you don't want or need those
things you'll probably just want to run 'trial $PROJECT' or 'nose
$PROJECT' or something.

Thanks,
J.
Permalink | Reply | 6 comments |
headers
Éric Araujo | 6 May 2011 19:42

Re: secondary testing tools

 Hi,

 Le 06/05/2011 12:09, Jamu Kakar a écrit :
> On Fri, May 6, 2011 at 4:11 AM, Rustom Mody <rustompmody <at> gmail.com> 
> wrote:
>> For running a battery of tests (in good-ol C projects), the Makefile
>> is often used.
>>
>> What is the recommended tool for orchestrating testing in python?

 There’s an emerging consensus about using “setup.py test”.  Such a 
 command is provided by setuptools, distutils2 (the new standard, which 
 will be included in Python 3.3. and released separately for 2.4-3.2), or 
 you can write one in ten lines if you want no dependency (I’ll post an 
 example on the Python Cookbook later).  The great thing about it is that 
 users don’t have to know what testing tools you use, they can just run 
 “setup.py test”.

> There are a number of ways to run unit tests in Python.  I like
> Twisted's trial runner a lot and usually have a Makefile with a check
> target, like:

 Why not “make test”?  Check, lint and test are different actions in my 
 mind: test runs the test suite, lint runs code checking tools, and check 
 verifies the packaging (it’s a distutils command provided in Python 2.7 
 and 3.x).

 Regards

_______________________________________________
testing-in-python mailing list
testing-in-python <at> lists.idyll.org
http://lists.idyll.org/listinfo/testing-in-python
Permalink | Reply | 4 comments |
headers
Fred Drake | 6 May 2011 19:50
Picon
Favicon
Gravatar

Re: secondary testing tools

On Fri, May 6, 2011 at 1:42 PM, Éric Araujo <merwok <at> netwok.org> wrote:
> Why not “make test”?  Check, lint and test are different actions in my mind:
> test runs the test suite, lint runs code checking tools, and check verifies
> the packaging (it’s a distutils command provided in Python 2.7 and 3.x).

I don't know what you think "make check" implies other than running
the tests, but...

GNUish tradition at least is that "make check" runs the tests.  Though
I suspect Guido prefers "make test", since he added that target.

--

-- 
Fred L. Drake, Jr.    <fdrake at acm.org>
"Give me the luxuries of life and I will willingly do without the necessities."
   --Frank Lloyd Wright
Permalink | Reply | 0 comments |
headers
Jamu Kakar | 6 May 2011 21:05
Picon
Gravatar

Re: secondary testing tools

Hi,

On Fri, May 6, 2011 at 7:42 PM, Éric Araujo <merwok <at> netwok.org> wrote:
> Le 06/05/2011 12:09, Jamu Kakar a écrit :
>> On Fri, May 6, 2011 at 4:11 AM, Rustom Mody <rustompmody <at> gmail.com> wrote:
>>>
>>> For running a battery of tests (in good-ol C projects), the Makefile
>>> is often used.
>>>
>>> What is the recommended tool for orchestrating testing in python?
>
> There’s an emerging consensus about using “setup.py test”.  Such a command
> is provided by setuptools, distutils2 (the new standard, which will be
> included in Python 3.3. and released separately for 2.4-3.2), or you can
> write one in ten lines if you want no dependency (I’ll post an example on
> the Python Cookbook later).  The great thing about it is that users don’t
> have to know what testing tools you use, they can just run “setup.py test”.

I guess this is good, but I'm not overly excited by having to add a
setup.py so that I can run my tests.  I tend to avoid setup.py until I
really need it.

>> There are a number of ways to run unit tests in Python.  I like
>> Twisted's trial runner a lot and usually have a Makefile with a check
>> target, like:
>
> Why not “make test”?  Check, lint and test are different actions in my mind:
> test runs the test suite, lint runs code checking tools, and check verifies
> the packaging (it’s a distutils command provided in Python 2.7 and 3.x).

For the same reasons that Fred mentions.  'make check' running the
tests is a long standing tradition.  I guess those of us with a
background in C programming with the Autotools will find this normal
and others will find it arbitrary.

Thanks,
J.

_______________________________________________
testing-in-python mailing list
testing-in-python <at> lists.idyll.org
http://lists.idyll.org/listinfo/testing-in-python
Permalink | Reply | 1 comment |
headers
Rustom Mody | 7 May 2011 04:38
Picon

Re: secondary testing tools

On Sat, May 7, 2011 at 12:35 AM, Jamu Kakar <jkakar <at> kakar.ca> wrote:
<snipped>
> For the same reasons that Fred mentions.  'make check' running the
> tests is a long standing tradition.  I guess those of us with a
> background in C programming with the Autotools will find this normal
> and others will find it arbitrary.

Quite a state of flux in these parts it looks?

I see in "Fate of Distutils"
http://tarekziade.wordpress.com/2010/03/03/the-fate-of-distutils-pycon-summit-packaging-sprint-detailed-report/

-----------------------
If you have followed what is going on with packaging since last year,
you might think: “distutils, setuptools, distribute and now distutils2
?, oh no!!!”

I was quite despaired right after the summit. All the work we did
during in the past year would not land into the standard library for
2.7, and all the pre- refactoring work I did, like making the test
coverage decent, was going to be useless for the stdlib.
-------------------------

I am supposed to teach this in a couple of weeks :-) and I am running
faster and faster (in circles)
Permalink | Reply | 0 comments |

Gmane