Re: Unit testing, ZUnit
--- In zope@egroups.com, Lalo Martins <lalo@h...> wrote: <snip>
We first conceived it as a kind of Zope-based version of unittestgui.py - you create a "TestRunner" object giving it the package, module and name of a TestSuite object generator (see the PyUnit documentation) and inside it you may click on some widget to run the tests and produce a "TestResult" object which you can inspect later. Does this sound like a good design?
Then I figured in the long run a Product isn't the best sollution; instead, fiddling with App/Product* sounds more like it, to allow developers to register tests just like they register classes, ZClass superclasses, _misc and help. Of course, just like the current registerHelp and others, it wouldn't be mandatory and not using it wouldn't break anything.
Then, in the Product's page in the Control Panel, there would be a tab "Test", where you'd be allowed to run the unit tests.
What do people think of this? What does DC think of this? Can I go ahead and develop it in this direction?
Kewl. ;^) please do! I've been test-infected ever since I started using JUnit about 8 months ago so I know the value of building a unittest framework for Zope. I even started playing around with PyUnit and integrating it with Zope... I got to the point where I had a ZPublisher-based framework that allowed me to have something like a function that had a relative url as its argument and it would return the rendered HTML... I then stored the string into a file and it would allow me easily build tests that compared the string output to the one stored in the file... I was planning to do more (e.g. get to the point where I have a function with a relative url as its argument which would return me the actual object -- this would then allow me to run its methods and check its properties, check assertions, etc., etc... but then, my "real" work interfered and I had to put my plans in the backburner for a while...(I might get back to this in a month or so, so I'm very interested in your project...keep us posted) I had envisioned it as something that ran on the commandline (not as a TTW thing) and the context in which I was using it for was that I would be developing a lot of python code and that running my test suite on the commandline would return the familiar "...." output that the commandline versions of Junit and PyUnit provide... it would also allow me to run the GUI version without changing any of my unittests... My intention was that most of the testing would be the testing of the application, so I didnt intend to test the ZServer part of Zope (I assumed that ZServer would be passing the right URL to the ZPublisher) -- instead, everything would be run locally and single-threaded...(of course, this framework is limited and can't do the testing of ZServer-related stuff -- e.g. virtual hosting stuff like ZServer -- but since I was more focused on the 'application', this wasn't such a big deal compared to the benefit of being able to run my tests locally and with the flexibility of running them either thru the commandline or thru a GUI... So I do have some questions about how you intend the ZUnit to be used... e.g. -- lets say I'm developing a Zope Application... I begin by writing the Python code interface, then I start writing the PyUnit test... in the the Setup section, I put in the code that hooks me into the Zope ZODB, installs the product, sets the properties, etc.; in the test section, I can get to the object, test my assertions, etc... and in the TearDown -- I back out my changes, etc... Then I add this test to my Test suite...etc., etc...Then to run this test, I...do...what? Also one coding caveat: when I started building my ZPublisher-based framework, I encountered a bug I couldn't easily solve: I could run my PyUnit tests fine using the commandline but when I tried to run them via the PyUnit GUI they failed : as far as I could tell, the GUI version of PyUnit did something esoteric with the "import" function (which would allow automatic reloading whenever you started it -- allowing you to leave the GUI up all the time and you could modify your python code and it would reload correctly (this is equivalent to JUnit's LoadingTestRunner) -- unfortunately, it reacted badly with Zope's 'esoteric' use of the "import" function as well ;^)... HTH. Butch Landingin butchland@yahoo.com http://squishdot.org PS. Sorry for the rambling, its been a while since I last posted to the list and I wanted to get a lot of things off my chest ;^) __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/
On Tue, Oct 24, 2000 at 04:35:58AM -0700, Butch Landingin wrote:
So I do have some questions about how you intend the ZUnit to be used... e.g. -- lets say I'm developing a Zope Application... I begin by writing the Python code interface, then I start writing the PyUnit test... in the the Setup section, I put in the code that hooks me into the Zope ZODB, installs the product, sets the properties, etc.; in the test section, I can get to the object, test my assertions, etc... and in the TearDown -- I back out my changes, etc... Then I add this test to my Test suite...etc., etc...Then to run this test, I...do...what?
Well, I imagine it like this: Setup: You create an object in the ZODB and set properties etc Test: Make the assertions Teardown: Only necessary if you make other unrelated changes, because ideally ZUnit would already discard your objects after the test is run In your Product, you would (like usual with PyUnit) implement a function (in the place of your choosing) which returns a newly-allocated TestSuite. Let's call this the "creator function". As for your question, how do you run it, this is exactly the difference between the two ZUnit sub-proposals. ZUnit Product: You create a TestRunner object somewhere (anywhere) in your ZODB. One of its properties, "suite", is the full Python module/object path of the creator function. When you click "run the tests" in the TestRunner, it creates an instance of TestResults, which runs the tests and accumulates the results; clicking on it later will format the results for you. ZUnit mods to the Product-related classes: On your Product's __init__, you give the creator function as the argument of a new function context.registerTests. Then on the Product object in the Control Panel, there will be a new tab "Unit test" or something. Clicking on it will give you a list of existing TestResults objects and a button to run the tests and create a new TestResults (more or less the same semantics as the TestRunner, but on the Control Panel). The big difference is (creating the TestRunner in an arbitrary location in the ZODB then setting the name of the creator function) versus (passing the creator function on Product initialization and running in the Control Panel). []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
participants (2)
-
Butch Landingin -
Lalo Martins