pyUnitPerf

[Grig]

I just released a Python port of Mike Clark's JUnitPerf. I called it
pyUnitPerf and it's available at
http://sourceforge.net/projects/pyunitperf. It is in a very early stage
of development, but I think it's pretty usable (and useful) as it is.

I already received an interesting comment from a hard-core Python user
from Switzerland:

"Problem with porting patterns/api's from java straight to python is
that most of the outcome feels unpythonic. I'll not go about my own
feelings python vs. java here now, but I just want to point out that
there's already a rather large core of hard-python users who refuse to
use pyUnit because of this, and pyUnitPerf's doomed to share this fate,
unless of course somebody decides along the way to make it sexy and
pythonic and takes on the trouble of lowering the red-flag again which
java has become to lots of folks."

My own experience with pyUnit has been very satisfactory and for me
personally pyUnitPerf scratches an itch.

I'm curious to find out more about people's feelings and opinions on
this. I don't want to begin a flame war, but my personal take on it is
that the various Java-based test frameworks are very useful and there's
a lack of corresponding frameworks in Python. I'm thinking about tools
such as HTTPUnit, Cactus, Abbot, The Grinder, and there are many
others. I'm happy to see Jython being used more and more in such tools
though (The Grinder, Test Maker, Marathon).

Grig

[Roy Smith]

"Grig" <gr************@gmail.com> wrote:

"Problem with porting patterns/api's from java straight to python is
that most of the outcome feels unpythonic. I'll not go about my own
feelings python vs. java here now, but I just want to point out that
there's already a rather large core of hard-python users who refuse to
use pyUnit because of this,

I'm curious what people find "un-pythonic" about PyUnit? I've used it,
and while some parts of it seem a little over-complex to me, I don't see
anything about it which is inherently un-pythonic. Is this just a case
of Not Invented Here?

[Mike Thompson]

Roy Smith wrote:

"Grig" <gr************@gmail.com> wrote:

"Problem with porting patterns/api's from java straight to python is
that most of the outcome feels unpythonic. I'll not go about my own
feelings python vs. java here now, but I just want to point out that
there's already a rather large core of hard-python users who refuse to
use pyUnit because of this,

I'm curious what people find "un-pythonic" about PyUnit? I've used it,
and while some parts of it seem a little over-complex to me, I don't see
anything about it which is inherently un-pythonic. Is this just a case
of Not Invented Here?

I've seen 'py.test' proposed as as a more pythonic unit test framework.
So its design may provide you with some clues. It can be found at:

http://codespeak.net/py/current/doc/...mand-line-tool

As far as I can see, the defining feature of py.test is the simplicity
of the API. Its impressively absent.

--
Mike

[Dieter Maurer]

"Grig" <gr************@gmail.com> writes on 28 Dec 2004 18:47:45 -0800:

...
My own experience with pyUnit has been very satisfactory and for me
personally pyUnitPerf scratches an itch.

We use "pyUnit" extensively and are mostly satisfied.

There is one essential problem we hit more often: setting up
and tearing down can take excessive time.
Often, we are forced to abandon the test independence
and let a complete set of tests share the main part of the fixture.
--
Dieter

[Peter Hansen]

Dieter Maurer wrote:

We use "pyUnit" extensively and are mostly satisfied.

There is one essential problem we hit more often: setting up
and tearing down can take excessive time.
Often, we are forced to abandon the test independence
and let a complete set of tests share the main part of the fixture.

That's not an issue with the framework, though, is it?
Just with your specific tests and application?

-Peter