Re: Switching from nose to unittest2 - how to continue after an error?
On Mon, Aug 25, 2014 at 4:47 PM, Terry Reedy tjre...@udel.edu wrote: I know of two ways to collect multiple failures within a test function: Thanks, but I mean multiple test failures. I fully expect a specific test to exit when it hits an assertion failure. I suspect my problem is due to lack of support for the assert statement by unittest. I'll just go back to nose1 for now. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Switching from nose to unittest2 - how to continue after an error?
On 8/26/2014 4:55 AM, Skip Montanaro wrote: On Mon, Aug 25, 2014 at 4:47 PM, Terry Reedy tjre...@udel.edu wrote: I know of two ways to collect multiple failures within a test function: Thanks, but I mean multiple test failures. I fully expect a specific test to exit when it hits an assertion failure. I obviously did not understand your question How to continue after an error? and still don't. If you want to be understood, give a snippet of code, what happens now, and what you want to happen. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Switching from nose to unittest2 - how to continue after an error?
On Tue, Aug 26, 2014 at 11:58 AM, Terry Reedy tjre...@udel.edu wrote: If you want to be understood, give a snippet of code, what happens now, and what you want to happen. Thanks, but not really necessary. I have retreated into nose-land. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Switching from nose to unittest2 - how to continue after an error?
It appears that unittest in Python 2.7 should be capable enough that I can abandon nose in favor of python -m unittest. How do I get it to continue past the first failure? The --help output indicates that a -f flag causes it to fail fast, however, that appears to be the default. How do I get it to continue after the first failure? FWIW, I am using something slightly newer than Python 2.7.5 (built from source sometime before 2.7.6 was released). Ugh... Still no simple test_* functions (everything has to be a method of a subclass of TestCase)? No support for plain old assert? *sigh* Never mind... Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Switching from nose to unittest2 - how to continue after an error?
On 25/08/2014 19:36, Skip Montanaro wrote: It appears that unittest in Python 2.7 should be capable enough that I can abandon nose in favor of python -m unittest. How do I get it to continue past the first failure? The --help output indicates that a -f flag causes it to fail fast, however, that appears to be the default. How do I get it to continue after the first failure? FWIW, I am using something slightly newer than Python 2.7.5 (built from source sometime before 2.7.6 was released). Ugh... Still no simple test_* functions (everything has to be a method of a subclass of TestCase)? No support for plain old assert? *sigh* Never mind... Skip If you wish to write tests using something that can be compiled out please don't let me stop you. Having said that if nose or even nose2 works for you why not stick with it? There's also testfixtures, pytest, doctest and presumably others. Horses for courses? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Switching from nose to unittest2 - how to continue after an error?
On Mon, Aug 25, 2014 at 1:59 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: If you wish to write tests using something that can be compiled out please don't let me stop you. Having said that if nose or even nose2 works for you why not stick with it? There's also testfixtures, pytest, doctest and presumably others. Horses for courses? The test cases are run independently of the actual installed code base, so use of the assert statement is, at best, a minor issue. We don't use -O where I work either. Certainly, for me, the possibility that code might get compiled out was outweighed by its convenience. The nose folks say nose v1 will no longer be extended, that nose2 is the future. Alas, the API changed for plugins (which I'm currently trying unsuccessfully to get working). A couple questions to that list have so far gone unanswered (granted one of them was today), and before my questions, the latest thread with any replies was dated Aug 6. (That indicates to me that the nose group is pretty quiet.) Seeing that nose2 was mostly unittest2 and no longer having any 2.7 constraint, I thought I would give it a try. Unfortunately, from my perspective it appears that the authors of that package mostly came up with a bunch of different spellings of assert, requiring a bunch of tedious unit test changes for no obvious benefit. I realize that is almost certainly an unfair criticism, that there is more under the covers, but the lack of support for the assert statement is a problem for me. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Switching from nose to unittest2 - how to continue after an error?
On 25/08/2014 20:54, Skip Montanaro wrote: On Mon, Aug 25, 2014 at 1:59 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: If you wish to write tests using something that can be compiled out please don't let me stop you. Having said that if nose or even nose2 works for you why not stick with it? There's also testfixtures, pytest, doctest and presumably others. Horses for courses? The test cases are run independently of the actual installed code base, so use of the assert statement is, at best, a minor issue. We don't use -O where I work either. Certainly, for me, the possibility that code might get compiled out was outweighed by its convenience. The nose folks say nose v1 will no longer be extended, that nose2 is the future. Alas, the API changed for plugins (which I'm currently trying unsuccessfully to get working). A couple questions to that list have so far gone unanswered (granted one of them was today), and before my questions, the latest thread with any replies was dated Aug 6. (That indicates to me that the nose group is pretty quiet.) Seeing that nose2 was mostly unittest2 and no longer having any 2.7 constraint, I thought I would give it a try. Unfortunately, from my perspective it appears that the authors of that package mostly came up with a bunch of different spellings of assert, requiring a bunch of tedious unit test changes for no obvious benefit. I realize that is almost certainly an unfair criticism, that there is more under the covers, but the lack of support for the assert statement is a problem for me. Skip There's activity on this list if it helps gmane.comp.python.testing.general I've also seen a reference to tox there. Whatever happened to There should be one-- and preferably only one --obvious way to do it.? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Switching from nose to unittest2 - how to continue after an error?
On 8/25/2014 2:13 PM, Skip Montanaro wrote: It appears that unittest in Python 2.7 should be capable enough that I can abandon nose in favor of python -m unittest. How do I get it to continue past the first failure? Unittest normally stops with the first failure in a test_function. If the asserts within a function are dependent (or normally passing), that may be what you want. I know of two ways to collect multiple failures within a test function: 1. Do it yourself. For instance, let iopairs be an iterable of input, expected-output pairs for a function f. def test_f(self): failures = [] for inp, expect in iopairs: actual = f(inp) if actual != expect: failures.append((inp, expect, actual)) assertFalse(failures, 'inp, expect, actual triples' 2. Use subtests, new in 3.4, and I suspect backported in unittest2 on PyPI. This can be combined with the 1. above. Suppose two functions should both pass the test above. def test_g_h(self): for f in (g, h): with self.subTest(f=f): body of test_f As for asserts (from next message): self.assertTrue is equivalent to assert, except it does not disappear with a compile flag. The other assertX methods resolve to assertTrue, but for some, such as assert raises, the equivalent in non-trivial. Even when the equivalent is trivial, the specific methods usually gives better diagnostic messages. This is especially true when comparing two non-empty collection for equality. Knowing what is a one but the the other is very helpful. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Switching from nose to unittest2 - how to continue after an error?
On 26/08/2014 6:12 AM, Mark Lawrence wrote: Whatever happened to There should be one-- and preferably only one --obvious way to do it.? :) Ignoring for a moment that one obvious way only applies to Python-the-language, when it comes to libraries, there's a few factors (IMO) that affect this: 1. Some people find it easier to write something from scratch that read docs for an existing product. 2. It's easier to reimplement an existing concept than come up with something new. This is actually a good thing, though, as monocultures die. Just chalk it up to evolutionary pressure :) -- https://mail.python.org/mailman/listinfo/python-list
