Mike.Olson at fourthought.com
Fri Jul 27 09:22:20 MDT 2001
Rob Riggs wrote:
> Uche Ogbuji wrote:
> >Our code *isn't* organized into classes and methods: we use the
> >scripting approach rather than copying Java: personally, I think
> >scripting makes much more sense than OO for testing.
> That's an interesting statement. I'm not sure I understand it though.
> With PyUnit, one essentially "scripts" a set of test cases. Those test
> cases are member functions of a class. The OO is pretty much incidental.
> It's not necessary that it be OO, but the fact that it is does not get
> in the way.
But it can as Sean pointed out in an example. We do the same, we take a
lot of input and expected data, and generated test cases based on this
data. By having to define each test case in a class, we need to do some
pretty cool meta programming to do the above. That or have one really
really big test case that tests the entire system.
> PyUnit seems similar enough to me. But rather than stand-alone helper
> functions, PyUnit's helper functions are member functions in a test
> Honestly, your comments above seems like a lot of NIH syndrome. JUnit
> was developed by none other than Erich Gamma and Kent Beck -- a couple
> of folks that have had a little bit to say about software development in
> the last few years. PyUnit is a translation of their efforts. So, please
> excuse me if I'm not impressed by the complaints of a couple of my
> fellow Python afficianados. I'm sure your testing scripts work just
> fine. But I haven't understood any of the arguements against PyUnit yet.
> But, hey, to each his own.
To me your one statement in the above defines the problem
"PyUnit is a translation of their efforts"
It is translated from something that was originally designed to test
Java. It was not originally designed to test Python and does not allow
you test test python in ways that you can develop python.
> I have found PyUnit to be flexible enough to meet all of my unit testing
> needs. I use it for testing all of my Python code. And we are even using
> it to unit test some really nasty PL/SQL stored procs (in preparation
> for later refactoring work). The framework has made setting up reliable
> and repeatable tests as simple as it can be made, IMHO.
Cool. I can very easily see how it would be really nice to use for some
> It seems to me that the arguments I've seen put forth against PyUnit so
> far are based on misperseptions by people who have not used it
> extensively. PyUnit is such a simple framework that there really isn't
> anything to get in the way of doing whatever one wishes.
I have used it and I disagree.
> Maybe I've missed the whole point of this discussion... In the end, the
> fact that more people are actually writing automated unit tests (no
> matter what tool they use) is a step in the right direction.
I agree 100%
> This message sent by the FRPythoneers mailing list.
> Unsubscribe: echo unsubscribe | FRPythoneers-request at lists.community.tummy.com
> URL: http://lists.community.tummy.com/mailman/listinfo/frpythoneers
Mike Olson Principal Consultant
mike.olson at fourthought.com +1 303 583 9900 x 102
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, http://4Suite.org
Boulder, CO 80301-2537, USA
XML strategy, XML tools, knowledge management
More information about the FRPythoneers