Re: Problem When Unit Testing with PMock
Peter, for a object foo who need a iterator to do a job, i write test to make sure the foo correctlly used the iterator, so a simple empty iterator is not enough. because in the case, i need to see if or not the foo called the iterator to get the proper data from it and do the proper translating on them. so, the mock iterator i need should be such an iterator which can returns be iterated out a lot of test data as i willed. i guess you are not familar with unit testing. we need mock objects not because they are hard to implemented, we need them to make the tests easy and fine. - narke -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem When Unit Testing with PMock
[EMAIL PROTECTED] wrote: Peter, for a object foo who need a iterator to do a job, i write test to make sure the foo correctlly used the iterator, so a simple empty iterator is not enough. because in the case, i need to see if or not the foo called the iterator to get the proper data from it and do the proper translating on them. so, the mock iterator i need should be such an iterator which can returns be iterated out a lot of test data as i willed. See Terry's reply which referenced my posting to better understand the point I was making. i guess you are not familar with unit testing. Your guess is wrong. we need mock objects not because they are hard to implemented, we need them to make the tests easy and fine. Thanks for the tutorial. :-) I'm rather well acquainted with unit testing and mock objects. My point was merely that what Terry suggested did not act the way I thought he was proposing that it acted, and I was hoping to correct that. Not having actually read and understood your entire original question, I didn't know at the time and still don't know what you *really* need, just that Terry's suggestion looked like a bit of a brain fart. :-) For what it's worth, I tend to be of the school that says that overuse of mock objects is a testing smell, and as part of acting on that belief I avoid using generic mock objects. Instead, I write minimal ones which are carefully customized for a particular test, to make sure that the resulting mock object's code clearly tells a reader of the test exactly what it is trying to accomplish. Generic mocks, on the other hand, tend to get overused and rarely make the tests very readable, IMHO. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem When Unit Testing with PMock
Peter, I'm so sorry, the letter was originally wrote to Terry, not to you! I guess Terry not very familar to unit testing because he said: -- cut -- I am not familiar with pmock, but my impression is that mock objects are for objects that you may not have available, such as a connection to a database or file or instance of an umimplemented class ;-). For such objects, the mock-ness consists in returning canned rather than actual fetched or calculated answers. Iterators, on the other hand, are almost as -- end -- and i just want to say, mocking object is a useful testing method , not was telling a tutorial. :-) What you said about the overuse of the generic mock object is very interesting. I did not think that before. I believe that use generic or customized mocks is a problem of balance, so we may call it Art :-) Below is my code, you may look it to understand my original question (sorry for the coding for i am totally a python newbie): --- import unittest from pmock import * from mainctr import MainCtr class MainCtrTest(unittest.TestCase): def testProcess(self): filePicker = MockFilePicker() filePicker.expectedNextCalls = len(MockFilePicker.fns) + 1 rpt0 = foo rpt1 = bar (router0, router1) = (Mock(), Mock()) router0.expects(once()).feedIn(eq(MockFilePicker.fns)) router1.expects(once()).feedIn(eq(MockFilePicker.fns)) router0.expects(once()).deliver() router1.expects(once()).deliver() router0.expects(once()).getDeliveredSrcList().will(return_value([fn0, fn2])) router1.expects(once()).getDeliveredSrcList().will(return_value([])) router0.expects(once()).getDeliveryRpt().will(return_value(rpt0)) router1.expects(once()).getDeliveryRpt().will(return_value(rpt1)) routes = [router0, router1] ctr = MainCtr(filePicker, routes) ctr.process() self.assertEquals(ctr.getProcessRpt(), [rpt0, rpt1]) filePicker.verify() router0.verify() router1.verify() class MockFilePicker: fns = [f0, f1, f2] idx = 0 nextCalls = 0 resetCalls = 0 expectedResetCalls = 1 expectedNextCalls = 0 processedSet = set() expectedProcessedSet = set([fn0, fn2]) rememberProcessedCalls = 0 expectedRememberProcessedCalls = 1 def __iter__(self): return self def reset(self): self.resetCalls += 1 def next(self): self.nextCalls += 1 if self.idx len(self.fns): self.idx += 1 return self.fns[self.idx - 1] else: raise StopIteration def processed(self, fn): self.processedSet.add(fn) def rememberProcessed(self): self.rememberProcessedCalls += 1 def verify(self): if self.nextCalls != self.expectedNextCalls: raise Exception(nextCalls: + str(self.nextCalls)) if self.resetCalls != self.expectedResetCalls: raise Exception(resetCalls: + str(self.resetCalls)) if self.processedSet != self.expectedProcessedSet: raise Exception(processedSet: + str(self.processedSet)) if self.rememberProcessedCalls != self.expectedRememberProcessedCalls: raise Exception(rememberProcessedCalls: + str(self.rememberProcessedCalls)) if __name__ == __main__: unittest.main() -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem When Unit Testing with PMock
[EMAIL PROTECTED] wrote: def mockit(): raise StopIteration now pass mockit() but it behaviors differenctly when pass in a mockit() and pass in an iterator with empty. so i think the code emulates nothing. Is it possible that what you really need is a generator function instead of just a regular one? def mockit(): raise StopIteration yield None (The presence of the yield will let the compiler generate the proper code for this to be a generator, but it will never actually hit the yield statement when it executes...) Just a thought. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem When Unit Testing with PMock
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] def mockit(): raise StopIteration This was meant to be a generator function. Peter corrected my error in leaving out a never reached yield to make it so. My apologies. Putting if False: yield None as the first line in the function has same effect. but it behaviors differenctly when pass in a mockit() and pass in an iterator with empty. so i think the code emulates nothing. I hope Peter's addition clarifies and improves the situation. My idea was/is that an iterator comsumer should be tested with an empty iterator. def intit(k): for i in range(k): yield i Now you mean define my own iteration without the help of pmock. That was also my intention above. 'mockit' was just a name, this could be 'mockintit'. there are still so many other methods in the iterator for pass in, I don't understand this. An iterator only has a trivial .__iter__ method and a usually nontrivial .next method. A generator function makes it easy to create as many iterators as you need. have to mock them one by one totally manually, its boring and thats the reason why i want pmock. I am not familiar with pmock, but my impression is that mock objects are for objects that you may not have available, such as a connection to a database or file or instance of an umimplemented class ;-). For such objects, the mock-ness consists in returning canned rather than actual fetched or calculated answers. Iterators, on the other hand, are almost as easily available as ints, lists, etc. Anything with the interator interface and behavior *is* an interator, though you could make one yield mock objects. Do as you wish once you understand whatever choices pmock gives you. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Problem When Unit Testing with PMock
Hi, Anyone was using pmock for unit testing with python? I met a problem and hope someone to help me. For short, the pmock seems can not mock a iterator object. For example, the tested object is foo, who need to send message to another object bar. So, to test the foo, I need mock a mockBar. But the bar is a iterator, the foo use the bar in this way: foo.method(self, bar): for n in bar: do somthing ... my purpose is create a mockBar and pass this mock object to foo.method(), but this ideal simply does not work. Python will complain that calling on an uniteraterable object. I'v already set anything like mockBar.expects(__iter__()) and mockBar.expects(next()). Does anyone has some clues? - narke -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem When Unit Testing with PMock
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Anyone was using pmock for unit testing with python? I met a problem and hope someone to help me. For short, the pmock seems can not mock a iterator object. Why bother? def mockit(): raise StopIteration now pass mockit() For example, the tested object is foo, who need to send message to another object bar. So, to test the foo, I need mock a mockBar. But the bar is a iterator, the foo use the bar in this way: foo.method(self, bar): for n in bar: do somthing ... To properly test the method, *also* feed it an iterator that yields a few objects of the appropriate type. Assuming n is to be an int... def intit(k): for i in range(k): yield i Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem When Unit Testing with PMock
def mockit(): raise StopIteration now pass mockit() but it behaviors differenctly when pass in a mockit() and pass in an iterator with empty. so i think the code emulates nothing. def intit(k): for i in range(k): yield i Now you mean define my own iteration without the help of pmock. but there are still so many other methods in the iterator for pass in, i have to mock them one by one totally manually, its boring and thats the reason why i want pmock. -- http://mail.python.org/mailman/listinfo/python-list