pyunit-interest Mailing List for PyUnit testing framework (Page 9)
Brought to you by:
purcell
Menu
▾
▴
pyunit-interest
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(12) |
Jun
(16) |
Jul
(6) |
Aug
|
Sep
(3) |
Oct
(7) |
Nov
(4) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(11) |
Mar
(7) |
Apr
(50) |
May
(9) |
Jun
(5) |
Jul
(33) |
Aug
(9) |
Sep
(7) |
Oct
(7) |
Nov
(17) |
Dec
(4) |
| 2002 |
Jan
(8) |
Feb
|
Mar
(14) |
Apr
(9) |
May
(13) |
Jun
(30) |
Jul
(13) |
Aug
(14) |
Sep
|
Oct
|
Nov
(2) |
Dec
(11) |
| 2003 |
Jan
(8) |
Feb
(3) |
Mar
(6) |
Apr
(5) |
May
(15) |
Jun
(5) |
Jul
(8) |
Aug
(14) |
Sep
(12) |
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(3) |
Jul
(4) |
Aug
(4) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(5) |
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sean A. <ze...@wo...> - 2002-03-14 23:56:41
|
On Thu, 2002-03-14 at 15:23, Patrick K. O'Brien wrote: > I have a tests directory containing a number of unittest test modules and > wanted an easy way to run every single test without having to create suit= es > in each module. Since I couldn't find anything like this in the docs, in > anyone else's code, or on the Python Cookbook. <snip/> FWIW, in the pybeep project (http://pybeep.sourceforge.net) we use a similar script (CVSROOT/test/testall.py), liberally filched from Mark Pilgrims most excellent Dive into Python (http://diveintopython.org/regression_divein.html) Sean Allen =20 |
|
From: Patrick K. O'B. <po...@or...> - 2002-03-14 23:17:52
|
I have a tests directory containing a number of unittest test modules and
wanted an easy way to run every single test without having to create suites
in each module. Since I couldn't find anything like this in the docs, in
anyone else's code, or on the Python Cookbook, I decided to create a simple
bit of code. I include it here in case anyone finds it useful. If you see a
mistake or a way to improve this, please let me know. And if you like it,
perhaps it could end up in the docs.
--- testall.py ---
#!/usr/bin/env python
__author__ = "Patrick K. O'Brien <po...@or...>"
__cvsid__ = "$Id: testall.py,v 1.1 2002/03/14 23:10:20 pobrien Exp $"
__revision__ = "$Revision: 1.1 $"[11:-2]
import unittest
import glob
import os
def suite():
"""Return a test suite containing all test cases in all test modules.
Searches the current directory for any modules matching test_*.py."""
suite = unittest.TestSuite()
for filename in glob.glob('test_*.py'):
module = __import__(os.path.splitext(filename)[0])
suite.addTest(unittest.defaultTestLoader.loadTestsFromModule(module))
return suite
if __name__ == '__main__':
unittest.main(defaultTest='suite')
---
Patrick K. O'Brien
Orbtech
|
|
From: Sean A. <ze...@wo...> - 2002-01-30 04:45:49
|
Thanks a lot.
Sean Allen
On Tue, 2002-01-29 at 20:14, Changjune Kim wrote:
It's simple and easy.
--------
import unittest
class J:
def __init__(self,someArg1,someArg2):
if someArg1<0 or someArg2<0:
raise Exception
print "foobar!"
class TestJay(unittest.TestCase):
def testBounds(self):
self.assertRaises(Exception, J, -30, 20)
if __name__=3D=3D'__main__':
unittest.main()
---------
----- Original Message -----=20
From: "Sean Allen"=20
To: "PyUnit"=20
Sent: Wednesday, January 30, 2002 9:00 AM
Subject: [Pyunit-interest] Unit testing constructors
Hello, sorry if this has been covered before
Currently, I am trying to implement a test suite for some objects.
The objects need to do bounds checking based on arguments to their
__init__() ctor. If the object is given initialization parameters that
are out of bounds, an Exception must be thrown.
So far, So good.
I am having a great deal of difficulty trying to get a test case to work
that does something like
(pseudo code)
...
self.assertRaise(Exception, (attempt to create the object), (args))
...
which basically tells me I have to supply an instance of the object I'm
trying to create as first argument, which is not really possible under
these conditions. The code works well in interactive testing, it's just
how to write the unit test
Any ideas? =20
Sean Allen
|
|
From: Changjune K. <jun...@or...> - 2002-01-30 04:15:27
|
<html> <body> <img src=3D"http://user9.orgio.net/orgiomail/button.php3?id=3Dimyyudwfzhw= zpgjtfuj&user=3Djuneaftn" width=3D"1" height=3D"1"> <pre> It's simple and easy. -------- import unittest class J: def __init__(self,someArg1,someArg2): if someArg1<0 or someArg2<0: raise Exception print "foobar!" class TestJay(unittest.TestCase): def testBounds(self): self.assertRaises(Exception, J, -30, 20) if __name__=3D=3D'__main__': unittest.main() --------- ----- Original Message -----=20 From: "Sean Allen" <ze...@wo...> To: "PyUnit" <pyu...@li...> Sent: Wednesday, January 30, 2002 9:00 AM Subject: [Pyunit-interest] Unit testing constructors Hello, sorry if this has been covered before Currently, I am trying to implement a test suite for some objects. The objects need to do bounds checking based on arguments to their __init__() ctor. If the object is given initialization parameters that are out of bounds, an Exception must be thrown. So far, So good. I am having a great deal of difficulty trying to get a test case to work that does something like (pseudo code) ... self.assertRaise(Exception, (attempt to create the object), (args)) ... which basically tells me I have to supply an instance of the object I'm trying to create as first argument, which is not really possible under these conditions. The code works well in interactive testing, it's just how to write the unit test Any ideas? =20 Sean Allen </pre> </body> </html> <br> --------------------------------------------------------<br> Best Free e-Mail Site Orgio.net <a href=3D"http://www.orgio.net/" target=3D= "_blank">http://www.orgio.net</a><br> =C6=C4=BF=F6=C0=AF=C0=FA=B0=A1 =BC=B1=C5=C3=C7=D1 =B8=DE=C0=CF 30M =B9=AB= =B7=E1 =C0=FA=C0=E5=B0=F8=B0=A3, =BC=F6=BD=C5=C8=AE=C0=CE=C0=C7 =BF=F8=C1= =B6 |
|
From: Sean A. <ze...@wo...> - 2002-01-30 00:00:55
|
Hello, sorry if this has been covered before Currently, I am trying to implement a test suite for some objects. The objects need to do bounds checking based on arguments to their __init__() ctor. If the object is given initialization parameters that are out of bounds, an Exception must be thrown. So far, So good. I am having a great deal of difficulty trying to get a test case to work that does something like (pseudo code) ... self.assertRaise(Exception, (attempt to create the object), (args)) ... which basically tells me I have to supply an instance of the object I'm trying to create as first argument, which is not really possible under these conditions. The code works well in interactive testing, it's just how to write the unit test Any ideas? =20 Sean Allen |
|
From: Steve P. <ste...@ya...> - 2002-01-22 08:13:10
|
Srikanth Mandava wrote: > > I'm running from a shell script after setting the PYTHONPATH. I get > a "can't open file <filename.py' "error even though the file is in the > PYTHONPATH. Any help is appreciated. Hi Srikanth, This type of question is probably best sent to the general python mailing list (see 'python-list' at http://mail.python.org/mailman/listinfo). My guess, though, is that your shell script contains something like: export PYTHONPATH=/some/directory python filename.py and that 'filename.py' is in '/some/directory'. Then, you are running the script from a different directory, and expecting that python will find 'filename.py' using 'PYTHONPATH'. This won't work, because Python doesn't use 'PYTHONPATH' to find scripts passed on the command-line; it only uses 'PYTHONPATH' to find modules loaded after the main script has started to run. Probably a better solution for you is simply: python /some/directory/filename.py Best of luck, -Steve -- Steve Purcell, Pythangelist Get testing at http://pyunit.sourceforge.net/ |
|
From: Srikanth M. <Sri...@co...> - 2002-01-22 07:50:15
|
Hi, I'm running from a shell script after setting the PYTHONPATH. I get a "can't open file <filename.py' "error even though the file is in the PYTHONPATH. Any help is appreciated. Thanks Srikanth ############################################################################ ########################## This email communication may contain CONFIDENTIAL INFORMATION and is intended only for the use of the intended recipients identified above. If you are not the intended recipient of this communication, you must not use, disclose, distribute, copy or print this email. If you have received this communication in error, please immediately notify the sender by reply email, delete the communication and destroy all copies. ############################################################################ ########################## |
|
From: robin a. j. <rob...@ea...> - 2002-01-20 14:27:37
|
In my view, this might be a nice **optional** convenience for debugging a small set of test cases, but I certainly do not want this as the default behavior; it could be cumbersome in cases where large numbers of tests fail and what I really want is a summary report. ----- Original Message ----- From: "Syver Enstad" <syv...@on...> To: <pyu...@li...> Sent: Saturday, January 19, 2002 6:03 PM Subject: [Pyunit-interest] Hooks for intergrating PyUnit with editor > > Hi, thanks to Steve Purcell for the extremely nice XP unit test > framework, I use it all the time. > > When using the tkguitestrunner I wanted to be able to see the source > when I had errors in my tests. There wasn't any hooks for it so I just > made a subclass, rape and paste inserted the original code in my > subclass and added my own code. I think it would be a cool feature if > one could hook a bit more elegantly into unittestgui so that it would > be easy for people to integrate with the editor of their choice. > > I would be willing to help out if that is needed. > > ---------------------------------------------------------------------------- ---- > > -- > > Vennlig hilsen > > Syver Enstad > |
|
From: Steve P. <ste...@ya...> - 2002-01-13 22:07:57
|
Hi Luke, Just starting to get back into gear as 2002 begins... You're quite right to point out that comparisons of floats using the 'assertEquals' method(s) should be 'fuzzy'. It's on my to-do list, and will certainly happen. Very best wishes, -Steve -- Steve Purcell, Pythangelist Get testing at http://pyunit.sourceforge.net/ _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
|
From: Luke D. <and...@sh...> - 2001-12-31 21:01:22
|
hi there,
well i have taken the plunge and started teaching myself python, along
the way i came across pyunit...
can i recommend that we change assertEquals to take a delta parameter?
the reason for this is so an approximate value will not fail the assert.
eg. writing a unittest that tests the area of a circle, you can set up a
'list' of known values consisting of radius and actual area
ie. (1, 3.1415927),
(2,12.566371)....
using the current implementation of assertEquals the provided area's
would fail the assertEquals
but if you use
assertEquals(result, actual, 0.0005) where 0.0005 is the delta and in
this case is approximate enough to pass and assertEquals test.
give the delta parameter a default value of 0 and AssertEquals will be
consistent with its current behaviour if you choose not to use a delta etc.
this means we redefine failUnlessEqual inside pyunit.py to
def failUnlessEqual(self, first, second, delta=0, msg=None):
"""Fail if the two objects are unequal as determined by the
difference between the actual value and the expected value.
a delta can be used to assert equal on approx values.
"""
"""if first != second:
raise self.failureException, (msg or '%s != %s' % (first,
second))
"""
if abs(first - second) > delta:
raise self.failureException, (msg or '%s != %s' % (first,
second))
make sense, hope so?
thanks,
luke
|
|
From: Steve P. <ste...@ya...> - 2001-12-12 09:54:04
|
Hi all, Courtesy of Suzuki Hisao, a Japanese translation of the PyUnit docs is now available at http://pyunit.sourceforge.net/pyunit_ja.html -Steve -- Steve Purcell, Pythangelist Get testing at http://pyunit.sourceforge.net/ |
|
From: Michal W. <sa...@ma...> - 2001-12-03 10:48:52
|
On Sun, 2 Dec 2001, Jesse W wrote:
> files anywhere. How do I make a test that requires the
> module to actually _send_ the files instead of simply
> faking it as my class now does? (code enclosed below)
> Thank you all for your time and answers,
Hey Jesse,
try it this way:
###############
class Connection:
def __init__(self, sender):
self.sender = sender
def send_file(self, file):
self.sender.send(file)
class MockSender:
def __init__(self):
self.files_sent=[]
def send(self, file):
self.files_sent.append(file)
class ConnectionTestCase(unittest.TestCase):
def testFileSent(self):
s = MockSender()
c = Connection (s)
c.send_file(TEST_FILE)
assert TEST_FILE in s.files_sent[],
'TEST_FILE not found in listfiles return value!'
##########
See how you can now pass in a RealSender instance with a
real send() method?
Cheers,
- Michal http://www.sabren.net/ sa...@ma...
------------------------------------------------------------
Give your ideas the perfect home: http://www.cornerhost.com/
cvs - weblogs - php - linux shell - perl/python/cgi - java
------------------------------------------------------------
|
|
From: Jesse W <je...@lo...> - 2001-12-02 23:45:47
|
Dear kind py-unit members,
I posted a question about a week ago regarding my attempts to create a website
updating program by test-first-design. I got a lot of useful answers.
I have now written two tests, and written a class which makes the tests succeed, but
the class does not actually send any files anywhere. How do I make a test that requires
the module to actually _send_ the files instead of simply faking it as my class now does?
(code enclosed below)
Thank you all for your time and answers,
Jesse Weinstein
--main.py----
lass Connection:
def __init__(self):
self.files_sent=[]
def connect(self):
pass
def send_file(self, file):
self.files_sent.append(file)
def listfiles(self):
return self.files_sent
---tests.py----
import main
TEST_FILE='c:/python22/mywork/updater/testfile'
class ConnectionTestCase(unittest.TestCase):
def setUp(self):
self.c=main.Connection()
self.c.connect()
def testConectionCanBeMade(self):
pass #just use setUp actions
def testFileSent(self):
self.c.send_file(TEST_FILE)
assert TEST_FILE in self.c.listfiles(), 'TEST_FILE not found in listfiles return value!'
<more unittest administration code (if __name__=='__main__', etc.) snipped>
|
|
From: Dave K. <dk...@bl...> - 2001-11-25 23:35:46
|
At 15:36 24/11/01 -0500, Michal Wallace wrote: >Hey Dave, > >Thanks for writing it. I've read through the code and it's >pretty slick. :) > >I have thought about extending it so that it could recognize >parameters. > >In java, I got used to EasyMock ( http://easymock.org ), >where you actually have two objects - a mock object and a >controller. You call the mock object, and then tell the >controller what result it should return. I think the way you >do this in python is a whole lot cleaner, but I miss being >able to test for parameters. > >Cheers, > >- Michal http://www.sabren.net/ sa...@ma... I know the Python Mock module does not fit the definition of Mock Objects as given in the article by Tim MacKinnon & Steve Freeman (http://www.sidewize.com/company/mockobjects.pdf), since the Mock object does not do any verification of the calls made, but leaves that up to the caller. I did think about adding some sort of internal checking, but since I didn't need it at the time I decided that YAGNI & DTSTTCPW applied and left it out. It is possible to test the parameters of a specific method by subclassing the Mock class and adding that method, but if you have to do that for every method it negates the benefit of having the Mock class in the first place. The biggest problem with the module as it stands is that it lets the user call any method on it, regardless of whether the call would be legal in the class being mocked. It should be fairly easy to extend it to check this by initialising it with a list of legal method names (and perhaps their allowable parameters), but there is a danger of making the whole thing so complex to use that it becomes simpler to hand code a specific mock class from scratch. I have just had a look at EasyMock, and it would be possible to do something similar to it in Python, passing in the class to be mocked and letting the Mock class extract all the legal methods and their parameters. Perhaps one day I will get round to adding it... Regards, Dave Kirby |
|
From: Michal W. <sa...@ma...> - 2001-11-24 20:36:02
|
On Sat, 24 Nov 2001, Dave Kirby wrote: > The module in question is in the file area of the Yahoo > extremeprogramming group - > http://groups.yahoo.com/group/extremeprogramming/files/PythonMock.zip > > As the author of the module, I welcome any feedback on > ways to improve it. Unfortunately I am not doing any > Python programming at work at the moment, so am not > currently using it. > > If there is any interest in adding the module to the > pyunit distribution, or hosting it separately on the > pyunit site then I would be more than happy to contribute > it. Hey Dave, Thanks for writing it. I've read through the code and it's pretty slick. :) I have thought about extending it so that it could recognize parameters. In java, I got used to EasyMock ( http://easymock.org ), where you actually have two objects - a mock object and a controller. You call the mock object, and then tell the controller what result it should return. I think the way you do this in python is a whole lot cleaner, but I miss being able to test for parameters. Cheers, - Michal http://www.sabren.net/ sa...@ma... ------------------------------------------------------------ Give your ideas the perfect home: http://www.cornerhost.com/ cvs - weblogs - php - linux shell - perl/python/cgi - java ------------------------------------------------------------ |
|
From: Michal W. <sa...@ma...> - 2001-11-24 20:26:42
|
On Fri, 23 Nov 2001, Jesse W wrote: > As I understand what you are saying here, I should make a > wrapper arround ftplib and then test that, although you > say maybe I don't need to because it is simple enough that > probblems should be obvious. But what if I don't know > exactly what calls to ftplib I will be needing? > > Anyway, when you're testing your code, you can substitute > > a mock function for the real thing. > Ah, this is the reason for doing the wrapper thing. But > how does this help me figure out what aspects of my design > to test? As I sort- of say above, should I test wheather > the responses I get from my wrapper are correct, or should > I assume they are correct, and if I assume this, what > should I test if I am doing test-first-design? I agree with June. Test the things that could break, and think of the test your code would have to pass for it to work, and write the test. So if you get to the point where you need to upload README.TXT to uh... cornerhost.com then you might want an "upload(file, server, dir)" function. Well, if that's the case, you write a mock object with an upload method (or a mock module, mock function, whatever) that does this: def mock_upload(self, file, server, dir): pass Then you can test your code, and in the setUp, substitute this method for the real one. The next step might be to ask, "well, what if something goes wrong?" ... Maybe cornerhost.com is down (not on my watch, but you get the idea).. So you simulate that situation: def mock_upload(self...): raise FTPExceptionOfSomeSort, "blah blah blah" Then you can test that your program handles the exception. But of course, you only write tests for things you actually care about. How do you know what tests to write? It depends on what you want your program to do. If you want your code to handle FTP errors gracefully, write a test for it. If you don't care about that, don't write the test. Cheers, - Michal http://www.sabren.net/ sa...@ma... ------------------------------------------------------------ Give your ideas the perfect home: http://www.cornerhost.com/ cvs - weblogs - php - linux shell - perl/python/cgi - java ------------------------------------------------------------ |
|
From: Dave K. <dk...@bl...> - 2001-11-24 20:25:59
|
>Date: Fri, 23 Nov 2001 11:24:13 -0500 (EST) >From: Michal Wallace <sa...@ma...> >Subject: Re: [Pyunit-interest] Aid requsted regarding test-first-design > >Jesse >This is a good time to use what they call "Mock Objects". >[snip...] >If you're mocking objects, there's actually a library that >lets you set up mock objects to return certain values for >different method calls, and count the number of times each >method has been called. Do a search for "python mock >objects" if you're interested. The module in question is in the file area of the Yahoo extremeprogramming group - http://groups.yahoo.com/group/extremeprogramming/files/PythonMock.zip As the author of the module, I welcome any feedback on ways to improve it. Unfortunately I am not doing any Python programming at work at the moment, so am not currently using it. If there is any interest in adding the module to the pyunit distribution, or hosting it separately on the pyunit site then I would be more than happy to contribute it. Dave Kirby |
|
From: Changjune K. <jun...@ha...> - 2001-11-24 01:49:27
|
It will be really helpful if you could tell us the real *thing* (code, maybe?) -- I'm afraid that I can't quite understand your point. ----- Original Message ----- From: "Jesse W" <je...@lo...> To: <pyu...@li...> Sent: Saturday, November 24, 2001 9:51 AM Subject: Re: [Pyunit-interest] Aid requsted regarding test-first-design > Michal- > Thank you for your answer. However, I still have some > difficulties. I will explain below. > Michal Wallace wrote: > > On Thu, 22 Nov 2001, Jesse W wrote: > > > Obviously I should not test _it_ because it is assumed to be > > > working, but I should test my calls to it. Or should I, because the > > > interface between an external library and my program does not have > > > anything to do with the program's _requirements_, does it? But > > > maybe I can because I can choose to create tests supporting that? > > This is a good time to use what they call "Mock Objects". > > > > Make an object (or a function, depending on your needs) that > > handles your FTP stuff. This should wrap the calls to > > ftplib. You can test this manually, or write automated test > > for it but keep them separate, or whatever. This kind of > > thing is usually visible enough that if something goes > > wrong, you know about it. > As I understand what you are saying here, I should make a wrapper > arround ftplib and then test that, although you say maybe I don't > need to because it is simple enough that probblems should be > obvious. But what if I don't know exactly what calls to ftplib I will be > needing? You don't test in advance. You think _in_ tests. If you want to do Z, describe Z as a test in a testing code, then try to make a code that'll pass it. > > Anyway, when you're testing your code, you can substitute > > a mock function for the real thing. > Ah, this is the reason for doing the wrapper thing. But how does > this help me figure out what aspects of my design to test? As I sort- You test all that could possibly break, while trying to implement what you want the system do for you. You don't need to worry about what to test in the first place. Desribe what you want the system do for you in test codes. > of say above, should I test wheather the responses I get from my > wrapper are correct, or should I assume they are correct, and if I Responses from wrappers or mock objects are correct, because you hard-coded correct answers already. > assume this, what should I test if I am doing test-first-design? > I hope I am being at least somewhat clear. > > Thank you for your time, > Jesse Weinstein > June |
|
From: Jesse W <je...@lo...> - 2001-11-24 00:54:11
|
Michal- Thank you for your answer. However, I still have some difficulties. I will explain below. Michal Wallace wrote: > On Thu, 22 Nov 2001, Jesse W wrote: > > Obviously I should not test _it_ because it is assumed to be > > working, but I should test my calls to it. Or should I, because the > > interface between an external library and my program does not have > > anything to do with the program's _requirements_, does it? But > > maybe I can because I can choose to create tests supporting that? > This is a good time to use what they call "Mock Objects". > > Make an object (or a function, depending on your needs) that > handles your FTP stuff. This should wrap the calls to > ftplib. You can test this manually, or write automated test > for it but keep them separate, or whatever. This kind of > thing is usually visible enough that if something goes > wrong, you know about it. As I understand what you are saying here, I should make a wrapper arround ftplib and then test that, although you say maybe I don't need to because it is simple enough that probblems should be obvious. But what if I don't know exactly what calls to ftplib I will be needing? > Anyway, when you're testing your code, you can substitute > a mock function for the real thing. Ah, this is the reason for doing the wrapper thing. But how does this help me figure out what aspects of my design to test? As I sort- of say above, should I test wheather the responses I get from my wrapper are correct, or should I assume they are correct, and if I assume this, what should I test if I am doing test-first-design? I hope I am being at least somewhat clear. Thank you for your time, Jesse Weinstein |
|
From: Michal W. <sa...@ma...> - 2001-11-23 16:23:28
|
On Thu, 22 Nov 2001, Jesse W wrote:
> Obviously I should not test _it_ because it is assumed to be working,
> but I should test my calls to it. Or should I, because the interface
> between an external library and my program does not have anything
> to do with the program's _requirements_, does it? But maybe I can
> because I can choose to create tests supporting that?
Jesse,
This is a good time to use what they call "Mock Objects".
Make an object (or a function, depending on your needs) that
handles your FTP stuff. This should wrap the calls to
ftplib. You can test this manually, or write automated test
for it but keep them separate, or whatever. This kind of
thing is usually visible enough that if something goes
wrong, you know about it.
Anyway, when you're testing your code, you can substitute
a mock function for the real thing.
For example, I have a function called "sendmail" that
actually sends mail out. But I don't want my tests sending
out mail all the time, so I do this:
def fakeit(email):
pass
class WhateverTestCase:
def setUp(self):
import module
module._sendmail = module.sendmail
module.sendmail = fakeit
If you're mocking objects, there's actually a library that
lets you set up mock objects to return certain values for
different method calls, and count the number of times each
method has been called. Do a search for "python mock
objects" if you're interested.
Cheers,
- Michal http://www.sabren.net/ sa...@ma...
------------------------------------------------------------
Give your ideas the perfect home: http://www.cornerhost.com/
cvs - weblogs - php - linux shell - perl/python/cgi - java
------------------------------------------------------------
|
|
From: Jesse W <je...@lo...> - 2001-11-23 06:48:31
|
Dear Interested Pyuniteers,
I am not sure that this is the proper forum for these questions,
so please pardon me(and suggest a more correct forum) if they are
off-topic.
I am writing a program to automate my website. I am attempting
to use code the tests first. This is my first attempt at successfully
using XP programming practices. Here is my idea of some of the
requirements for this project:
Requirements:
Automate my website maintenance
Update files on the website
Send files to the website
Connect to the website server
I have reached a stuck point. I hope someone can help me.
If I am going to use ftplib to connect to the server, how should I test
it?
Obviously I should not test _it_ because it is assumed to be working,
but I should test my calls to it. Or should I, because the interface
between an external library and my program does not have anything
to do with the program's _requirements_, does it? But maybe I can
because I can choose to create tests supporting that?
If I have failed to include necessary or useful information, I will
gladly provide it when I know what it is.
Thank you very much for your time,
Jesse Weinstein
|
|
From: Joel Q. <joe...@ho...> - 2001-11-22 13:23:19
|
Hi, I would like to write a text test runner. Where should I start ? With the testloader object ? After make a test runner or should I use another approche ? Thanks for any help Joel |
|
From: Changjune K. <jun...@ha...> - 2001-11-21 05:16:21
|
Have you ever wished that Python had interface enforcement like Java?
You can have it with unittest module, even better than Java's.
There are two ways, which can be combined for purpose. I have been using these
ways and have been had lots of benefits from them. I'd like to share them with
you and want to hear your comments.
1) Syntactic Checking
Put the following method in the TestCase class or inherit and make a new class
with it:
def assertImplements(self, implementation, interface, msg=None):
from pydoc import allmethods
from inspect import getargspec, formatargspec
infMethods=allmethods(interface)
for methodName,method in infMethods.items():
print method.im_class,methodName
impMethod=getattr(implementation,methodName,None)
if impMethod is None:
raise self.failureException, (msg or '%s.%s is not implemented in
%s.' %(method.im_class.__name__,methodName,implementation.__name__))
impFunc=impMethod.im_func
impFuncSig=getargspec(impFunc)
infFuncSig=getargspec(getattr(interface,methodName).im_func)
if impFuncSig != infFuncSig:
raise self.failureException, (msg or '%s: %s != %s'
%
(methodName,formatargspec(*impFuncSig),formatargspec(*infFuncSig)))
When you have an interface like,
class BagInterface:
def isEmpty(self):
raise NotImplementedError
class StackInterface(BagInterface):
def push(self, anObject):
raise NotImplementedError
def pop(self):
raise NotImplementedError
And you have this implementation:
class ListStack:
'''
Implements StackInterface
'''
def __init__(self):
self._s=[]
def push(self, anObject):
self._s.append(anObject)
def pop(self):
return self._s.pop()
def isEmpty(self):
return len(self._s)==0
Now you can check this in your test file as,
self.assertImplements(ListStack,StackInterface)
It does check the existence of all methods of the interface in the
implementation, and the signature -- arguments specs. Even the variable name.
You might think it too constrained or weird but I found this more helpful than
not, because Python isn't statically typed. You can't be sure if it implements
with right arguments or not, but if you can check the variable names, you can
be quite sure you haven't confused the arguement order and etc. This works
well when you use good naming convention for arguments.
There are surely some more sophistication that can be added on this.
2) Semantic Checking
You know interfaces sometimes can deceive you -- it could be fictitious
without semantic guarantee. With unittests, however, the interfaces can
guarantee semantics as well.
The following code will tell, (If the client implements StackInterface with
ListStack, she'll make a unittest module for that and name it
"test_StackList". In the test, she just imports all the tests from
StackInterface so that interface compliances are guaranteed. She might add
some ListStack specific testcases in the same module test_StackList.)
#------------------------------------------------
#StackInterface.py
import unittest
class StackInterface: #or put this whole class as a doc string
'''Anything that implements this should pass the unittests in
StackInterface with its own MyImpl
'''
def push(self, anObject):
raise NotImplementedError
def pop(self):
raise NotImplementedError
def isEmpty(self):
raise NotImplementedError
class _Object: #helper object representing _anything_
pass
class TestStackInterface(unittest.TestCase):
def setUp(self):
self.stack=MyImpl()
def testPushAndPop(self):
o=_Object()
self.stack.push(o)
self.assertEqual(o, self.stack.pop())
def testPopOnEmpty(self):
self.assert_(self.stack.isEmpty())
self.assertRaises(IndexError,self.stack.pop)
def testPushAllAndPopAll(self):
oList=[_Object() for i in range(10)]
for each in oList:
self.stack.push(each)
oList.reverse()
for each in oList:
self.assertEqual(each, self.stack.pop())
MyImpl=StackInterface #please override this with the real implementation
if __name__=='__main__': # you won't run this module directly though
unittest.main()
#------------------------------------------------
#ListStack.py
from StackInterface import StackInterface
class ListStack(StackInterface):
def __init__(self):
self._s=[]
def push(self, anObject):
self._s.append(anObject)
def pop(self):
return self._s.pop()
def isEmpty(self):
return len(self._s)==0
#------------------------------------------------
#test_ListStack.py
import unittest
import StackInterface
from ListStack import ListStack
StackInterface.MyImpl=ListStack
from StackInterface import * #if you want to implement several
#interfaces just import all of
them here
if __name__=='__main__':
unittest.main()
|
|
From: Chuck E. <Chu...@ya...> - 2001-11-02 22:25:08
|
At 02:17 PM 11/2/2001 -0800, Yvan Charpentier wrote: >I am calling a C-function that returns an unsigned int >Python, though, allocate a integer (so i get the wrong value (negative >number)) > >How would i force Python to allocate a unsigned int? > >Yvan > >PS: Thanks for all the previous answers, you guys are helping me a lot Your welcome, but is this really related to pyunit? If it's not, I would suggest the comp.lang.python list, which you can also post to via pyt...@py..., although you may need to monitor the group via usenet since not all replies will be sent back to you. You can also access it via Google groups: http://groups.google.com/groups?hl=en&safe=off&group=comp.lang.python -Chuck |
|
From: Fred L. D. Jr. <fd...@ac...> - 2001-11-02 22:20:56
|
Yvan Charpentier writes:
> I am calling a C-function that returns an unsigned int
> Python, though, allocate a integer (so i get the wrong value (negative
> number))
>
> How would i force Python to allocate a unsigned int?
This sounds like a general Python question; shouldn't this be
addressed to comp.lang.python?
Anyway, to represent a C unsigned int in Python, you need to use a
Python "long", which can have any integer value. To create this from
a C extension, use this:
unsigned long i = my_function();
return PyLong_FromUnsignedLong(i);
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation
|
19 messages has been excluded from this view by a project administrator.
