ANN: pry unit testing framework

[Terry Reedy]

| Aldo Cortesi wrote:
| > Thus spake Kay Schluehr ([email protected]):

**tweet** <Time out>

| >> Aldo, when you confuse inheritance ( using an OO framework properly )
| >> with monkey patching no one can draw much different conclusions than I
| >> did.
| >
| > I guess you do always run the risk of being pelted with something from
| > the peanut gallery when you release something in public -

Yes, Guido gets attacked too.

| > maybe I'll think twice about doing so next time.

As did I. But I hope you continue to share.

| > The only "confused" person here is you - I still say that it is NOT
| > possible to provide the functionality Pry does by extending unittest in
| > any sane way. Now, if you don't agree with this, please prove me wrong
| > through reasoned argument or shut up. Do NOT, however, accuse me of not
| > knowing what inheritance or monkeypatching is unless you want to look
| > stupid and make my killfile.
| >
| >> But raving against unittest.py and anti-hyping it for mostly trivial
| >> reasons and with shallow reasoning has become a fashion.

Let's see.. Aldo shares his project. Someone asks why he did what he did.
He explains. And you call this raving. To me, that is unfair and a
mischaracterization of his intent and action.

|>> Now we see
| >> alternatives that do little more than what can be achieved by adding
| >> two abstract methods to the TestSuite base class and overwrite a few
| >> methods of the TestLoader base class ( maybe I'm wrong about it but I
| >> guess the discussion has become too heated to clarify this point using
| >> technical arguments ).

The real proof would be code that does what you claim.

| >> I just felt it was a good opportunity to debunk this unittest.py anti-
| >> hype. I'm sorry it has gone too personal.

I gather that you were irritated at 'raving unittest.py anti-hype' before
Aldo wrote a word here. Perhaps 'debunking' would go better in a separate
thread that was not aimed at anyone in particular.

| > You can choose to use Pry or not, as you please. I would, however, ask
| > that you stop whining incessantly about how it's not compatible with
| > YOUR favourite framework, despite the fact that compatibility would
| > gain YOU very little and ME nothing at all. As I said in my response to
| > Michele, you lose the benefits of compatibility as soon as your tests
| > use any of the features an extension might add. To me, this means the
| > burden is not worth it. Since I designed and wrote Pry, I get to make
| > that choice, not you, and the type of feeble, offensive "argument"
| > you've provided is unlikely to change my mind.

| Unpleasantly personal replies of this type are unwelcome here. Please
| restrict your arguments to technical ones or refrain from posting.

Steve, Kay is the one who started and repeated 'unpleasantly personal
replies'. You should better have addressed her.

| Kay at least has a long history as a contributor in this group, so
| people know how to interpret her remarks and know that her contributions
| are made on the basis of a deep understanding of Python. She is far from
| belonging to the "peanut gallery", and to suggest otherwise betrays
| either ignorance, arrogance, or both.
|
| As a newcomer, however, your responses make you seem to be complaining
| that the world isn't grateful for your contributions, yet you don't seem
| to even consider the possibility that might be happening because you
| aren't explaining them well enough. To truculently suggest that reasoned
| responses make you less likely to contribute to open source in future
| suggests that you weren't ready to start in the first place.

So you, as an old-timer, excuse the old-timer for starting a spat and scold
the newcomer for responding. To me, that smells.

**Tweet** <Time in>

Terry Jan Reedy
Another old-timer, with a long history of contributions also.

 

[Michele Simionato]

Kay at least has a long history as a contributor in this group, so
people know how to interpret her remarks and know that her contributions
are made on the basis of a deep understanding of Python. She is

I am pretty much sure you are making a gender mistake with Kay
Schluehr here For the rest, I do fully agree with your remarks.
Kay +1, Aldo -1!

Michele Simionato

 

[Aldo Cortesi]

Steve,

Kay at least has a long history as a contributor in this group, so
people know how to interpret her remarks and know that her contributions
are made on the basis of a deep understanding of Python. She is far from
belonging to the "peanut gallery", and to suggest otherwise betrays
either ignorance, arrogance, or both.

While I'm not a regular poster on this list, I have been reading it for
nearly 10 years, so I probably have more context here than you suspect.
At least one mail to this list and a number of personal emails to me
suggest that it is Kay and and indeed you who are temporarily out of
line with the tone of the list. A more impartial re-reading of the
debate so far might make you judge my final, admittedly angry, response
more fairly.



Regards,



Aldo

 

[Steve Holden]

Steve,


While I'm not a regular poster on this list, I have been reading it for
nearly 10 years, so I probably have more context here than you suspect.
At least one mail to this list and a number of personal emails to me
suggest that it is Kay and and indeed you who are temporarily out of
line with the tone of the list. A more impartial re-reading of the
debate so far might make you judge my final, admittedly angry, response
more fairly.

To be fair I wasn't commenting on the whole thread, more on the angry
nature of your final reply, and didn't really consider Kay's remarks
fully. So perhaps I could ask *both* of you to be more civil to each
other, and leave it at that? Storm in a teacup, of course. I'm sure war
won;t be declared about this.

Consider the 200,000 (?) readers of the group who *didn't* complain
about your post and your software as supporters, if you like

regards
Steve

 

[Steve Holden]

Steve,


While I'm not a regular poster on this list, I have been reading it for
nearly 10 years, so I probably have more context here than you suspect.
At least one mail to this list and a number of personal emails to me
suggest that it is Kay and and indeed you who are temporarily out of
line with the tone of the list. A more impartial re-reading of the
debate so far might make you judge my final, admittedly angry, response
more fairly.

To be fair I wasn't commenting on the whole thread, more on the angry
nature of your final reply, and didn't really consider Kay's remarks
fully. So perhaps I could ask *both* of you to be more civil to each
other, and leave it at that? Storm in a teacup, of course. I'm sure war
won;t be declared about this.

Consider the 200,000 (?) readers of the group who *didn't* complain
about your post and your software as supporters, if you like

regards
Steve

 

[Kay Schluehr]

To be fair I wasn't commenting on the whole thread, more on the angry
nature of your final reply, and didn't really consider Kay's remarks
fully. So perhaps I could ask *both* of you to be more civil to each
other, and leave it at that? Storm in a teacup, of course. I'm sure war
won;t be declared about this.

Nah, no war. It's more like sports

Regards, Kay

 

[Aldo Cortesi]

Thus spake Matthieu Brucher ([email protected]):

One last question : does it take doctests into account ?

I'm afraid that Pry is unashamedly incompatible with any other unit
testing method in existence, including but not limited to doctest,
unittest, nose and py.test.

Some day I might experiment with extending Pry to gather and run
doctests and unittests. At this stage, however, I don't believe the
(significant) effort would be worth it.



Regards,




Aldo

 

[Ryan Ginstrom]

Some day I might experiment with extending Pry to gather and run
doctests and unittests. At this stage, however, I don't believe the
(significant) effort would be worth it.

That's very unfortunate. Until it plays better with others, I
don't believe the effort of using this package will be worth it.[/QUOTE]

I also don't want to be negative, since Aldo obviously has put a lot of work
into this framework. But since it's not compatible with other frameworks, it
will mainly be attractive to people not writing unit tests now, which means
they:
1) Think writing unit tests is too much of a hassle, or
2) Ae new (Python) programmers

In either case, the key requirement of the framework would be ease of use,
but Pry's selling point is actually its sophisticated options. Thus it
appears that the potential user base is rather small...

Regards,
Ryan Ginstrom

 

[Aldo Cortesi]

Thus spake Ben Finney ([email protected]):

Which makes the deliberate deviations from PEP 8 naming a large black
mark against it.

You're misunderstanding the intent of PEP 8, which was never supposed
to dogmatically enforce a naming standard on all Python projects
everywhere. You're also vastly overstating the impact of a minor naming
convention choice. Calling this a "large black mark" smacks of
scare-mongering to me.

That's very unfortunate. Until it plays better with others, I don't
believe the effort of using this package will be worth it.

Each of the third-party testing frameworks that have cropped up in this
thread extends unittest in some incompatible way. If you use any of
these extensions, it means that your unit test suite is tied to that
particular test framework. If you have an existing suite of unit tests
that you can't or don't want to convert, I'm afraid that Pry is indeed
not for you. Pry is not intended to be a general engine for running
tests written for other frameworks.

I should also note that converting from unittest to Pry is quite simple
- Pry's test structure is a superset of unittest's, and AutoTree was
explicitly written to make "unittest-style" testing possible, meaning
that no _structural_ change is needed for conversion. The most onerous
part is converting to assertion-based testing, something that will
improve the clarity and readability of your tests anyway.




Regards,



Aldo

 

[Steve Holden]

Thus spake Ben Finney ([email protected]):


You're misunderstanding the intent of PEP 8, which was never supposed
to dogmatically enforce a naming standard on all Python projects
everywhere. You're also vastly overstating the impact of a minor naming
convention choice. Calling this a "large black mark" smacks of
scare-mongering to me.

It probably reflects personal preference, but it's a preference that
many people will maintain. I understand that PEP 008 was largely
directed at standard library authors and maintainers, but anything that
claims wide utility should have ambitions to be included in the standard
library, and hence PEP 008 conformance would be a plus.

Each of the third-party testing frameworks that have cropped up in this
thread extends unittest in some incompatible way. If you use any of
these extensions, it means that your unit test suite is tied to that
particular test framework. If you have an existing suite of unit tests
that you can't or don't want to convert, I'm afraid that Pry is indeed
not for you. Pry is not intended to be a general engine for running
tests written for other frameworks.

A reasonable enough point of view, but it means that you are just one of
a number of competing frameworks. While you are earnest about pry's
advantages you have a lot of work to do to move people away form the
entrenched testing frameworks they are used to.

I should also note that converting from unittest to Pry is quite simple
- Pry's test structure is a superset of unittest's, and AutoTree was
explicitly written to make "unittest-style" testing possible, meaning
that no _structural_ change is needed for conversion. The most onerous
part is converting to assertion-based testing, something that will
improve the clarity and readability of your tests anyway.

Time will tell.

regards
Steve

 

[Steve Holden]

Thus spake Ben Finney ([email protected]):


You're misunderstanding the intent of PEP 8, which was never supposed
to dogmatically enforce a naming standard on all Python projects
everywhere. You're also vastly overstating the impact of a minor naming
convention choice. Calling this a "large black mark" smacks of
scare-mongering to me.

It probably reflects personal preference, but it's a preference that
many people will maintain. I understand that PEP 008 was largely
directed at standard library authors and maintainers, but anything that
claims wide utility should have ambitions to be included in the standard
library, and hence PEP 008 conformance would be a plus.

Each of the third-party testing frameworks that have cropped up in this
thread extends unittest in some incompatible way. If you use any of
these extensions, it means that your unit test suite is tied to that
particular test framework. If you have an existing suite of unit tests
that you can't or don't want to convert, I'm afraid that Pry is indeed
not for you. Pry is not intended to be a general engine for running
tests written for other frameworks.

A reasonable enough point of view, but it means that you are just one of
a number of competing frameworks. While you are earnest about pry's
advantages you have a lot of work to do to move people away form the
entrenched testing frameworks they are used to.

I should also note that converting from unittest to Pry is quite simple
- Pry's test structure is a superset of unittest's, and AutoTree was
explicitly written to make "unittest-style" testing possible, meaning
that no _structural_ change is needed for conversion. The most onerous
part is converting to assertion-based testing, something that will
improve the clarity and readability of your tests anyway.

Time will tell.

regards
Steve

 

[Roy Smith]

I should also note that converting from unittest to Pry is quite simple
- Pry's test structure is a superset of unittest's, and AutoTree was
explicitly written to make "unittest-style" testing possible, meaning
that no _structural_ change is needed for conversion. The most onerous
part is converting to assertion-based testing, something that will
improve the clarity and readability of your tests anyway.

I've been following this thread for a while with a mix of amusement and
alarm. Contributing code to the community is a good thing, and should be
celebrated. If people like it, they will use it. If they don't, it will
be ignored. None of which justifies the hostility this thread seems to
have degenerated into.

In any case, I don't understand why you say that unittest doesn't use
"assertion-based testing". They seem like assertions to me. What am I
missing?

 

[Aldo Cortesi]

Thus spake Roy Smith ([email protected]):

I've been following this thread for a while with a mix of amusement and
alarm. Contributing code to the community is a good thing, and should be
celebrated. If people like it, they will use it. If they don't, it will
be ignored. None of which justifies the hostility this thread seems to
have degenerated into.

I agree entirely - I've been astonished by the whole fracas myself. I'm
offering Pry simply as something neat I wrote that other people might
find useful, no more.

In any case, I don't understand why you say that unittest doesn't use
"assertion-based testing". They seem like assertions to me. What am
I missing?

While you can use the built-in "assert" statement in unittest tests, it
turns out to be annoying in practice, especially during rapid
code-test-code iterations. The problem is that assert traceback errors
are uninformative - when "assert a == b()" fails, there's no way to
tell what a and b() were in this context. Unittest copes with this with
convenience methods - instead you write self.assertEqual(a, b()), which
then gives you proper error reporting.

I think it was py.test that first introduced some magic that picks up
the AssertionError traceback, parses the original expression, and then
re-evaluates its components to give you an error featuring the
"disassembled" assertion expression. This approach has been adopted by
nose and independently by pry. While re-evaluation has some
limitations (like not dealing well with expressions that change state),
using assertions makes for more fluid and natural expression in tests.
Maybe "assertion-based" is not an exact phrase to describe this -
saying that these frameworks support "expanded error reporting for
Python assert statements" might be more accurate.



Regards,




Aldo

 

[Aldo Cortesi]

Thus spake Steve Holden ([email protected]):

It probably reflects personal preference, but it's a preference that
many people will maintain. I understand that PEP 008 was largely
directed at standard library authors and maintainers, but anything
that claims wide utility should have ambitions to be included in the
standard library, and hence PEP 008 conformance would be a plus.

Well, that's an entirely different conversation. Inclusion in the
standard library has not always benefitted libraries - in fact, the
standard library contains a number of examples of modules that have
calcified due to the strict demands for interface backwards
compatibility. Many of these could have been excellent if development
and refactoring had continued. The library cleanup for Py3K may fix
some of these problems, but then we're stuck again until, well, Py4K,
and by then we'll all be too busy swanning about in our flying cars and
having holidays on Mars to care.

So, no, I don't think inclusion in the standard library should be a
universal ambition, and it's certainly not one I have for Pry.






Regards,



Aldo

 

[Aldo Cortesi]

Thus spake Ben Finney ([email protected]):

PEP 8 only has the force that people grant it. Nevertheless, it's a
style guide that's widely accepted in the Python community, and
adhering to it in one's code makes it easier to read for the majority,
because it reduces the needless inconsistencies between different
bodies of code.

Conversely, deliberately diverging from the widely-accepted style
guide increases the cognitive load on the reader; if that divergence
is not done for a very good reason, one is imposing needless burden on
every reader of the code.

This is getting silly. Let's recap. You are upset because I prefer this
widely-used method naming convention:

object.myName()

.... to this one, which was recently adopted as a recommendation in PEP
008 for modules in the standard library:

object.my_name()

By doing so, you say, I am "imposing needless burden on every reader"
of my code... Well, lets look at the facts:

First, PEP 8 recommends a naming scheme only for the standard library,
and it is not follwed consistently even there.

Second, mixedCase is very common both inside and outside the Python
project. No-one who codes regularly in Python can be unfamiliar with
it, even if they never stray beyond the standard library.

Third, this is a minor, recently-introduced convention. Anyone would
dislike code that chose not to name classes with an initial capital, or
used something other than "self" as the first method parameter. Method
naming conventions are far, far fuzzier. The primary issue is simply
to clearly distinguish between words in multi-word names - mymethodname
would be bad, MYMETHODNAME would be even worse, but my_method_name and
myMethodName are both perfectly legible.


You are mis-interpreting the intent behind PEP-8 if you think its
authors intended to provoke shrill public condemnation of any module
that dares to use a long-standing, widely-used alternative method
naming scheme. In fact, PEP 8 contains an entire section warning
against exactly this kind of inflexible and small-minded application of
its recommendations - perhaps you should read it sometime.

When distributing code with the expectation that others use it, it's a
large black mark if it deliberately shun the widely-accepted,
easily-followed coding standards, for the above reasons.

I don't see why that would be scary. If you find it so, you have my
sympathy.

You re-enforce the point you're trying to counter beautifully. Thanks
for driving my argument home.






Regards,


Aldo