Re: assertraises behaviour
2012/7/16 Peter Otten __pete...@web.de: No, I don't see how the code you gave above can fail with an OSError. Can you give an example that produces the desired behaviour with nose? Maybe we can help you translate it to basic unittest. -- http://mail.python.org/mailman/listinfo/python-list Well this is what I meant: import unittest class TestWithRaises(unittest.TestCase): def test_first(self): assert False def test_second(self): print(also called) assert True if __name__ == '__main__': unittest.main() in this case also the second test is run even if the first fails.. But that's probably easy because we just need to catch exceptions for every method call, so it's not exactly the same thing.. -- http://mail.python.org/mailman/listinfo/python-list
Re: assertraises behaviour
Am 17.07.2012 11:06, schrieb andrea crotti: import unittest class TestWithRaises(unittest.TestCase): def test_first(self): assert False def test_second(self): print(also called) assert True if __name__ == '__main__': unittest.main() in this case also the second test is run even if the first fails.. The reason for that is that the unit testing framework catches and handles the error. It calls both test functions in some unspecified order and logs the result. Calls to two separate test functions are thereby separated from each other. This is intentionally so, but I think you can also give the unit testing framework a flag that makes it abort after the first error. In no way will the exception escape from the unittest.main() call though, it is all caught and handled inside, also by intention. But that's probably easy because we just need to catch exceptions for every method call, so it's not exactly the same thing.. I don't understand what you want to say here. I also don't understand what your problem in general is. I guess there are some expectations which are not satisfied, but you haven't explained those explicitly yet. Uli -- http://mail.python.org/mailman/listinfo/python-list
RE: assertraises behaviour
import unittest class TestWithRaises(unittest.TestCase): def test_first(self): assert False def test_second(self): print(also called) assert True if __name__ == '__main__': unittest.main() in this case also the second test is run even if the first fails.. The reason for that is that the unit testing framework catches and handles the error. It calls both test functions in some unspecified order and logs the result. Calls to two separate test functions are thereby separated from each other. This is intentionally so, but I think you can also give the unit testing framework a flag that makes it abort after the first error. In no way will the exception escape from the unittest.main() call though, it is all caught and handled inside, also by intention. But that's probably easy because we just need to catch exceptions for every method call, so it's not exactly the same thing.. I don't understand what you want to say here. I also don't understand what your problem in general is. I guess there are some expectations which are not satisfied, but you haven't explained those explicitly yet. I think Andrea wants to do the same thing but with nose and not unittest. Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
Re: assertraises behaviour
On 17/07/2012 18:49, Prasad, Ramit wrote: import unittest class TestWithRaises(unittest.TestCase): def test_first(self): assert False def test_second(self): print(also called) assert True if __name__ == '__main__': unittest.main() in this case also the second test is run even if the first fails.. The reason for that is that the unit testing framework catches and handles the error. It calls both test functions in some unspecified order and logs the result. Calls to two separate test functions are thereby separated from each other. This is intentionally so, but I think you can also give the unit testing framework a flag that makes it abort after the first error. In no way will the exception escape from the unittest.main() call though, it is all caught and handled inside, also by intention. But that's probably easy because we just need to catch exceptions for every method call, so it's not exactly the same thing.. I don't understand what you want to say here. I also don't understand what your problem in general is. I guess there are some expectations which are not satisfied, but you haven't explained those explicitly yet. I think Andrea wants to do the same thing but with nose and not unittest. Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. Do what? Like Ulrich Eckhart I simply don't understand what she's getting at. Perhaps it's a problem with Englsh being a second language issue rather than Python itself. Thankfully I'm sure that everything will come out in the wash. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: assertraises behaviour
On 7/17/2012 5:06 AM, andrea crotti wrote: Well this is what I meant: import unittest class TestWithRaises(unittest.TestCase): def test_first(self): assert False def test_second(self): print(also called) assert True if __name__ == '__main__': unittest.main() in this case also the second test is run even if the first fails. Or test_first is run even if test_second fails. The point is that unittest runs separate test methods independently. They could theoretically be run simultaneously. Tests within a method are dependent unless you take steps to make them independent by not having them raise exceptions or by catching exception as you go until you are done. If you make a error_list of problems as you go, you could end the method with assertFalse(error_list). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
RE: assertraises behaviour
On 17/07/2012 18:49, Prasad, Ramit wrote: import unittest class TestWithRaises(unittest.TestCase): def test_first(self): assert False def test_second(self): print(also called) assert True if __name__ == '__main__': unittest.main() in this case also the second test is run even if the first fails.. The reason for that is that the unit testing framework catches and handles the error. It calls both test functions in some unspecified order and logs the result. Calls to two separate test functions are thereby separated from each other. This is intentionally so, but I think you can also give the unit testing framework a flag that makes it abort after the first error. In no way will the exception escape from the unittest.main() call though, it is all caught and handled inside, also by intention. But that's probably easy because we just need to catch exceptions for every method call, so it's not exactly the same thing.. I don't understand what you want to say here. I also don't understand what your problem in general is. I guess there are some expectations which are not satisfied, but you haven't explained those explicitly yet. I think Andrea wants to do the same thing but with nose and not unittest. Ramit Do what? Like Ulrich Eckhart I simply don't understand what she's getting at. Perhaps it's a problem with Englsh being a second language issue rather than Python itself. Thankfully I'm sure that everything will come out in the wash. -- Cheers. Mark Lawrence. I get the impression that nose stops running tests once any test fails instead of running all tests and listing all the tests and their pass/fail status (like unittest). Granted that is just what I get from the context as I read it as I have no knowledge of nose. Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
Re: assertraises behaviour
To clarify my problem, I just thought that assertRaises if used as context manager should behave as following: - keep going if the exception declared is raised - re-raise an error even if catched after the declared exception was catched I was also confused by the doc a bit: Test that an exception is raised when /callable/ is called with any positional or keyword arguments that are also passed to assertRaises() http://docs.python.org/library/unittest.html#unittest.TestCase.assertRaises. The test passes if /exception/ is raised, is an error if another exception is raised, or fails if no exception is raised which speaks about when it's not used as a context manager.. I understand why it's not possible and it's not a big issue though.. -- http://mail.python.org/mailman/listinfo/python-list
assertraises behaviour
I found that the behaviour of assertRaises used as a context manager a bit surprising. This small example doesn't fail, but the OSError exception is cathed even if not declared.. Is this the expected behaviour (from the doc I would say it's not). (Running on arch-linux 64 bits and Python 2.7.3, but it doesn the same with Python 3.2.3) import unittest class TestWithRaises(unittest.TestCase): def test_ass(self): with self.assertRaises(AssertionError): assert False, should happen raise OSError(should give error) if __name__ == '__main__': unittest.main() -- http://mail.python.org/mailman/listinfo/python-list
Re: assertraises behaviour
Am 16.07.2012 15:38, schrieb andrea crotti: This small example doesn't fail, but the OSError exception is cathed even if not declared.. Is this the expected behaviour (from the doc I would say it's not). (Running on arch-linux 64 bits and Python 2.7.3, but it doesn the same with Python 3.2.3) import unittest class TestWithRaises(unittest.TestCase): def test_ass(self): with self.assertRaises(AssertionError): assert False, should happen raise OSError(should give error) The OSError isn't catched as the code never reaches the line with raise OSError. In other words raise OSError is never executed as the exception raised by assert False stops the context manager. You should avoid testing more than one line of code in a with self.assertRaises() block. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: assertraises behaviour
2012/7/16 Christian Heimes li...@cheimes.de: The OSError isn't catched as the code never reaches the line with raise OSError. In other words raise OSError is never executed as the exception raised by assert False stops the context manager. You should avoid testing more than one line of code in a with self.assertRaises() block. Christian -- http://mail.python.org/mailman/listinfo/python-list Ok now it's more clear, and normally I only test one thing in the block. But I find this quite counter-intuitive, because in the block I want to be able to run something that raises the exception I catch (and which I'm aware of), but if another exception is raised it *should* show it and fail in my opinion.. -- http://mail.python.org/mailman/listinfo/python-list
Re: assertraises behaviour
andrea crotti wrote: 2012/7/16 Christian Heimes li...@cheimes.de: The OSError isn't catched as the code never reaches the line with raise OSError. In other words raise OSError is never executed as the exception raised by assert False stops the context manager. You should avoid testing more than one line of code in a with self.assertRaises() block. Christian -- http://mail.python.org/mailman/listinfo/python-list Ok now it's more clear, and normally I only test one thing in the block. But I find this quite counter-intuitive, because in the block I want to be able to run something that raises the exception I catch (and which I'm aware of), but if another exception is raised it *should* show it and fail in my opinion.. That doesn't sound like it's clearer. Perhaps it helps if you translate your code into a standard try...except: class A(Exception): pass ... class B(Exception): pass ... try: ... raise A ... raise B ... except A as e: ... print caught %r % e ... caught A() The try block is left at the raise A' statement -- Python doesn't have an equivalent of Basic's resume next. Therefore B (or OSError) is never raised. PS: Strictly speaking your assert False is equivalent to if __debug__ and False: raise AssertionError Therefore you *can* trigger the OSError by invoking the interpreter with the -O option: $ python -c 'assert False; raise OSError' Traceback (most recent call last): File string, line 1, in module AssertionError $ python -O -c 'assert False; raise OSError' Traceback (most recent call last): File string, line 1, in module OSError -- http://mail.python.org/mailman/listinfo/python-list
Re: assertraises behaviour
Good thanks, but there is something that implements this behaviour.. For example nose runs all the tests, and if there are failures it goes on and shows the failed tests only in the end, so I think it is possible to achieve somehow, is that correct? -- http://mail.python.org/mailman/listinfo/python-list
Re: assertraises behaviour
andrea crotti wrote: Good thanks, but there is something that implements this behaviour.. For example nose runs all the tests, and if there are failures it goes on and shows the failed tests only in the end, so I think it is possible to achieve somehow, is that correct? No, I don't see how the code you gave above can fail with an OSError. Can you give an example that produces the desired behaviour with nose? Maybe we can help you translate it to basic unittest. -- http://mail.python.org/mailman/listinfo/python-list
