[TIP] Generating tests, II (was: Re: Meta-test methods...)
C. Titus Brown
ctb at msu.edu
Fri Apr 24 12:57:05 PDT 2009
On Fri, Apr 24, 2009 at 03:35:27PM -0400, Douglas Philips wrote:
-> On or about 2009 Apr 24, at 3:10 PM, C. Titus Brown indited:
-> >I'm trying to figure out why I dislike the non-decorator tagging so
-> >much; I think because I want
-> >to know what the signature of a test function is up front, without
-> >looking at the end. That conflicts with 'yield' too, though. I guess
-> >I'm just inconsistent.
-> Cracking open a method and examining how it is implemented is just
-> plain and simple: a hack. If it were in code I was reviewing, I would
-> classify it as a bug. If there were no other way, sure, it might be
-> tolerable. But there are other ways. At least two that that are
-> actually Pythonic.
In the end I'm just not sure it matters. It's never caused problems
for me; if it does, I'll re-examine it. Since nose (especially in
retrospect) *solved* a lot of other problems for me, I'm going to take
the neutral with the good.
-> If the py.test/nose dudes had used new naming convention, would you
-> really have balked at it? Would you have thought it complicated or un-
-> usable? Would you have thought "Oh, that makes sense, this is a
-> different part of the testing eco-system" of course it needs a
-> different name?
Naah, I probably would have just used it when I needed it.
-> Is there an objection here other than that you've become familiar with
-> one particular way of doing things?
No, not really. Didn't I just admit to being inconsistent? What more
do you want?? ;)
-> Is that why you object to buildbot? Its a pretty complex system (a hot
-> pot in the boiling-a-frog analogy). But if you're already familiar
-> with a system (say a testing framework), then a slow accretion of
-> features seems simple. Familiarity is the slow-heating-pot. I find
-> these kinds of systems fascinating... how much familiarity is taken
-> for simplicity.
That's... a different conversation. If I respond, will people promise
not to expect me to respond to any further questions? ;)
I have a number of objections to buildbot. Here are some of the better
- reliance on twisted, with associated installation problems on
- no standard way to specify metadata to be returned from clients
(think: rich status; coverage; built eggs; various other
generated test files)
- no standard scripting interface to let me query buildbot masters
about slave status.
- a GUI that doesn't scale well to dozens of buildslaves.
- always-on connection between master and slaves.
- "anonymous" build slaves not allowed (or easy).
- reliance on master to specify arbitrary commands to be executed on
slaves, with associated security nightmare.
There are a bunch of reasons I love buildbot, too -- it works, it's
ridiculously configurable, and it supports far more complex build
environments than I ever hope to have. I promoted it for years and am
still going to, when it's appropriate for the situation. But life moves
on. The thought of setting up buildbot on Snakebite, in particular, gave
me the heeby-jeebies: installation and maintenance of buildbot is,
frankly, annoying, and I just don't have the time.
After we get pony-build working we can revisit this discussion to
figure out why pony-build sucks, and then we can plan pony-bot or
something ;). But for now, I'm personally satisfied that I need
People might look up DART 2 or cdash (I think cdash is the next
incarnation? not sure) for an interesting alternative, and I'd be
interested in hearing back from people who've tried Hudson.
C. Titus Brown, ctb at msu.edu
More information about the testing-in-python