Re: [Tutor] unittest decorators
> From: Peter Otten <__pete...@web.de> >To: tutor@python.org >Sent: Thursday, April 3, 2014 3:13 PM >Subject: Re: [Tutor] unittest decorators > > >Albert-Jan Roskam wrote: > >> The unittest module has some really handy decorators: @unittest.skip >> and @unittest.skipIf. I use the former for temporary TODO or FIXME things, >> but I use the latter for a more permanent thing: >> @unittest.skipif(sys.version_info()[0] > 2). Yet, in the test summary you >> just see error, skipped, failed. Is it possible to not count the skipIf >> tests? > >You mean like this? > >$ cat skiptest.py >import unittest >import sys > >def hide_if(condition): > def g(f): > return None if condition else f > return g > >class T(unittest.TestCase): > @hide_if(sys.version_info[0] > 2) > def test_two(self): > pass > @hide_if(sys.version_info[0] < 3) > def test_three(self): > pass > >if __name__ == "__main__": > unittest.main() >$ python skiptest.py -v >test_two (__main__.T) ... ok > >-- >Ran 1 test in 0.000s > >OK >$ python3 skiptest.py -v >test_three (__main__.T) ... ok > >-- >Ran 1 test in 0.000s > >OK >$ Wow, yes, this is exactly what I meant! Thank you! Now the "bad/code smell/TODO" skips are separated from the legitimately skipped tests. >> (other than using if-else inside the test --not really a bad >> solution either ;-)? > >I don't understand that remark. Ok, that was indeed a bit cryptic, sorry. I meant something like this: class T(unittest.TestCase): def test_combined(self): if(sys.version_info[0] > 2: pass else: pass ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] data driven programming
On 04/04/14 03:33, Alex Kleider wrote: And to some extent Python is an example of a data driven design since function (and method) calls are associated with dictionaries (ie Python namespaces). Can you elaborate, please, on what you mean by pointing out that the fact that Python's function and method calls are associated with dictionaries makes it 'an example of data driven design?' I'm not clear on that relationship. Thanks, Alex Most of Python is built on dictionaries under the surface. When you define a function you create a function object and associate it with a name. In other words you store the name as a key in a dictionary and have the function object as the value. When you call the function Python looks up the name in the dictionary and calls the associated object. This is very similar to what was recommended to you to avoid the long list of if/elif. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] conditional execution
spir wrote: > On 04/01/2014 06:24 PM, Zachary Ware wrote: >> Hi Patti, >> >> On Tue, Apr 1, 2014 at 11:07 AM, Patti Scott wrote: >>> I've been cheating: comment out the conditional statement and adjust >>> the indents. But, how do I make my program run with if __name__ == >>> 'main': >>> main() at the end? I thought I understood the idea to run a module >>> called >>> directly but not a module imported. My program isn't running, though. >> >> The simple fix to get you going is to change your ``if __name__ == >> 'main':`` statement to ``if __name__ == '__main__':`` (add two >> underscores on each side of "main"). To debug this for yourself, try >> putting ``print(__name__)`` right before your ``if __name__ ...`` >> line, and see what is printed when you run it in different ways. >> >> Hope this helps, and if you need any more help or a more in-depth >> explanation of what's going on, please don't hesitate to ask :) > > And you don't even need this idiom if your module is only to be executed > (not imported). Just write "main()". How do you write tests for the code in the module then? ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unittests
I would like to thank both Steven and Danny for their explanations. They were much easier for me to understand than the documentation. I now think that I understand what I have to do and how I proceed. Thanks to you both for spending so much time on the answer. Sydney On 01/04/2014 18:54, Danny Yoo wrote: Yes, that unit test was written by Danny (I assume -- I suppose he might have copied it from somewhere else.) Oh, who knows where I got that code from. :P --- Sydney, you can also take a look at some of the official documentation of the unittest library: https://docs.python.org/2/library/unittest.html#basic-example You don't have to read all of it, but touching on it and knowing where the documentation and reference is can be helpful. The "assertAlmostEqual" is part of the library, https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertAlmostEqual In Scott's case, he was computing with floating point, so writing the tests to use inexact almost-equality comparison seemed reasonable to me. You might find this also useful: http://www.diveintopython.net/unit_testing/ Although they might be a bug in the test! In this case, Danny intends that as a deliberately buggy test -- 1.732... is *not* "approximately equal" to 2, at least not according to the rules of unittest. As a side note, when I'm writing tests, I usually write them deliberately wrong the first time and run them to make sure that the framework is properly reporting errors. Only after I see failing tests do I put in the right values for the test. It helps me gain more confidence that the universe is all right. I am quite unclear how one proceeds to set up unittests. Functions that take inputs and return values are usually easy to test. For simple programs, express a piece of functionality and some property you expect that functionality to have. In pure computations like math functions, you can state the inputs and expected outputs as a test. By the way, if we can't even do that, to express the expected output of our functions, then that might be a sign that we don't understand what we're trying to code! So there's a good reason to consider test cases early: it forces us to put a stake in the ground and say: "This is what the function is supposed to do, and if it doesn't do this, the code is wrong." If I know that a properly functioning f() is supposed to behave like this: f(9) ==> 3 f(10) ==> 42 f(1) ==> 32 then I want to write those concrete cases as tests. An easy way to do so is to use the unittest library to write those tests. We can write the cases above as the following test: ### class MyTests(unittest.TestCase): def testCrazyFunction(self): self.assertEqual(f(9), 3) self.assertEqual(f(10), 42) self.assertEqual(f(1), 32) ### What this means is that I have some expectations on what the function is supposed to do, apart from how it is actually coded. That's important, to express those expectations, because usually you trust your expectations more than you trust the implementing code. So if the test breaks, usually it's the code that's broken, so it gives a quick canary-in-the-coalmine. If you want to explore this more, check for Kent Beck's: "Test-driven Development: By Example". ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor -- Sydney Shall ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unittests
- Original Message - > From: Sydney Shall > To: tutor@python.org > Cc: > Sent: Friday, April 4, 2014 3:12 PM > Subject: Re: [Tutor] unittests > > I would like to thank both Steven and Danny for their explanations. > They were much easier for me to understand than the documentation. > I now think that I understand what I have to do and how I proceed. > Thanks to you both for spending so much time on the answer. > Sydney Sydney, I found this a very useful book: http://www.amazon.com/Python-Testing-Beginners-Daniel-Arbuckle/dp/1847198848 regards, Albert-Jan ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unittests
On 04/04/2014 14:55, Albert-Jan Roskam wrote: - Original Message - From: Sydney Shall To: tutor@python.org Cc: Sent: Friday, April 4, 2014 3:12 PM Subject: Re: [Tutor] unittests I would like to thank both Steven and Danny for their explanations. They were much easier for me to understand than the documentation. I now think that I understand what I have to do and how I proceed. Thanks to you both for spending so much time on the answer. Sydney Sydney, I found this a very useful book: http://www.amazon.com/Python-Testing-Beginners-Daniel-Arbuckle/dp/1847198848 regards, Albert-Jan Dear Albert-Jan, Many thanks for the suggestion. I will have a look at the book. Best wishes, Sydney -- Sydney Shall ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] data driven programming
On 2014-04-04 01:51, Alan Gauld wrote: On 04/04/14 03:33, Alex Kleider wrote: And to some extent Python is an example of a data driven design since function (and method) calls are associated with dictionaries (ie Python namespaces). Can you elaborate, please, on what you mean by pointing out that the fact that Python's function and method calls are associated with dictionaries makes it 'an example of data driven design?' I'm not clear on that relationship. Thanks, Alex Most of Python is built on dictionaries under the surface. When you define a function you create a function object and associate it with a name. In other words you store the name as a key in a dictionary and have the function object as the value. When you call the function Python looks up the name in the dictionary and calls the associated object. This is very similar to what was recommended to you to avoid the long list of if/elif. Thank you. I thought there was something more. ak ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
