By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,587 Members | 1,575 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,587 IT Pros & Developers. It's quick & easy.

Propagating poorly chosen idioms

P: n/a

Peter> unitttest is surely not the be all and end all of Python unit
Peter> testing frameworks... but it's one of the batteries included in
Peter> the standard distribution, and it's pretty trivial to get started
Peter> using it, unless maybe you try to go by the documentation instead
Peter> of by the examples...

This reminded me of something I noticed awhile ago. If you're learning
something new, there is a tendency to find a working example to start from,
then modify it to suit your needs. This is fine as far as it goes, however,
if the idioms used in the code you're cloning are suboptimal, they get
cloned.

Unittest's API is difficult enough for me to remember (at least the initial
framework I need to put together) that I generally hunt down some previous
unittest usage, clone it and start from there. I no longer have any idea
what the original unittest example was that got me started using it in the
first place (probably something in the distro's docs). I can only hope it
was a good example.
From that standpoint the simpler API of py.test seems attractive.


Skip
Jul 18 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Skip Montanaro wrote:
Unittest's API is difficult enough for me to remember (at least the initial
framework I need to put together) that I generally hunt down some previous
unittest usage, clone it and start from there. I no longer have any idea
what the original unittest example was that got me started using it in the
first place (probably something in the distro's docs). I can only hope it
was a good example.


That's a really good point. I do the exact same thing. It's not like
Unittest is all that complicated, but it's just complicated enough that
I can't remember all the details when I want to write a new one... I've
been putting off looking into py.test for a while, but maybe I need to
finally do so...

STeVe
Jul 18 '05 #2

P: n/a
[Skip Montanaro]
This reminded me of something I noticed awhile ago. If you're learning
something new, there is a tendency to find a working example to start from,
then modify it to suit your needs. This is fine as far as it goes, however,
if the idioms used in the code you're cloning are suboptimal, they get
cloned.

Unittest's API is difficult enough for me to remember (at least the initial
framework I need to put together) that I generally hunt down some previous
unittest usage, clone it and start from there. I no longer have any idea
what the original unittest example was that got me started using it in the
first place (probably something in the distro's docs). I can only hope it
was a good example.


If it was the distro or tutorial example, I hope you thought it was good.

I added those examples to the docs with the intention facilitating
cut-and-paste jobs so folks could get up and running quickly.

The remainder of the unittest docs are somewhat obtuse and uninspiring.
From that standpoint the simpler API of py.test seems attractive.


That is their number one selling point. I hope they don't lose it as the
package evolves to include doctests and such.

Raymond Hettinger
Jul 18 '05 #3

P: n/a
"Raymond Hettinger" <vz******@verizon.net> wrote:
The remainder of the unittest docs are somewhat obtuse and uninspiring.


QOTW, perhaps?
Jul 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.