Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #100334 > unrolled thread

Re: python unit test frame work

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: python unit test frame work Peter Otten <__peter__@web.de> - 2015-12-12 14:49 +0100

#100334 — Re: python unit test frame work

Ganesh Pal wrote:

> On Thu, Dec 10, 2015 at 9:20 PM, Peter Otten <__peter__@web.de> wrote:
>> Ganesh Pal wrote:
>>
> 
>> I recommend that you reread the unittest documentation.
>>
>> setUpClass() should be a class method, and if it succeeds you can release
>> the ressources it required in the corresponding tearDownClass() method.
>> As written the flags and the setUp()/tearDown() seem unnecessary.
>>
> 
> Thanks to peter , Cameron and  Ben Finney , for replying to my various
> question post . I needed a hint  on the below
> 
> 
> 1. If there is a setUpClass exception or failure , I don't want the
> unittest to run ( I don't have teardown ) how do I handle this  ?
>     The traceback on the console  looks very bad  it repeats for all
> the test cases  , that means if I have 100 testcases if setup fails .
> I will get the failure for all the test cases
> 
> #c_t.py
> EEEE
> ======================================================================
> ERROR: test01: test_01_inode_test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "c_t.py", line xx, in setUp
>     self.setupClass()
>   File "c_t.py", line xxx, in TestSetup
>     self.TestSetup()
>   File "c_t.py", line xx, in corruptSetup
>     sys.exit("/tmp is not mounted ...Exiting !!!")
> SystemExit: /tmp is not mounted ...Exiting !!!
> ======================================================================
> ERROR: test02
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "c_t.py", line 162, in  test_02_hardlink_test
>     self.inject_failures['test02']))
> KeyError: 'test02'
> 
> Ran 2 tests in 0.003s
> FAILED (errors=2)

Don't invoke sys.exit(), raise a meaningful exception instead. Then in 
setUpClass() you can catch the expected exceptions and raise a SkipTest. 
Example:

$ cat mayfail.py
import os
import unittest

def setup_that_may_fail():
    if "FAIL" in os.environ:
        1/0

class MyTests(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        try:
            setup_that_may_fail() # placeholder for your actual setup
        except Exception as err:
            raise unittest.SkipTest(
                "class setup failed") # todo: better message

    def test_one(self):
        pass

    def test_two(self):
        pass

if __name__ == "__main__":
    unittest.main()

When the setup succeeds:

$ python mayfail.py
..
----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK

Now let's pretend a failure by setting the FAIL environment variable.
(In your actual code you won't do that as you get a "real" failure)
$ FAIL=1 python mayfail.py
s
----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK (skipped=1)

There's one oddity with this approach -- only one skipped test is reported 
even though there are two tests in the class, neither of which is run.

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web