Re: Python unit test framework to fire 1000 unique concurrent requests (rmlibre)

2019-08-29 Thread rmlibre
If you want to try out some libraries to build your own tests, you could
try aiohttp, aiodns, and asyncio. The requests using these libraries are
made asynchronously, not completely in parallel, but produce a similar
effect at lower cost. Some examples and docs on these can be found here:
https://docs.aiohttp.org/en/v2.3.5/

I also recently came across this talk where the author created a server
to resolve 100 million requests to a server using asyncio. You can find
the talk here: https://www.youtube.com/watch?v=Mj-Pyg4gsPs

Also, Raymond Hettinger gave a talk on useful testing modules, which
could be helpful in deciding how to create your tests:
https://www.youtube.com/watch?v=ARKbfWk4Xyw




On 2019-08-29 16:00, python-list-requ...@python.org wrote:
> Send Python-list mailing list submissions to
>   python-list@python.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://mail.python.org/mailman/listinfo/python-list
> or, via email, send a message with subject or body 'help' to
>   python-list-requ...@python.org
> 
> You can reach the person managing the list at
>   python-list-ow...@python.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-list digest..."
> 
> Today's Topics:
> 
>1. Re: Python unit test framework to fire 1000 unique concurrent
>   requests (Pankaj Jangid)
>2. Re: How do I decouple these two modules? (Andrea D'Amore)
>3. Re: An "Object" class? (Cristian Cocos)
>4. Re: An "Object" class? (Chris Angelico)
>5. Fwd: installation problem (fateme jbr)
>6. Re: Fwd: installation problem (DL Neil)
>7. Re: How to use regex to search string between {}? (Jason Friedman)
>8. Compare zip lists where order is important (Sayth Renshaw)
>9. Re: How to use regex to search string between {}? (Sayth Renshaw)
>   10. if STREAM.isatty(): (Hongyi Zhao)
>   11. Re: An "Object" class? (Alan Bawden)
>   12. Re: Compare zip lists where order is important (Sayth Renshaw)
>   13. Re: Compare zip lists where order is important (Sayth Renshaw)
>   14. [SOLVED] Re: Compare zip lists where order is important
>   (Sayth Renshaw)
>   15. pandas loc on str lower for column comparison (Sayth Renshaw)
>   16. unable to to install paython (Alemu Geletew)
>   17. Re: [SOLVED] Re: Compare zip lists where order is important
>   (Peter Otten)
>   18. Re: Compare zip lists where order is important (Frank Millman)
>   19. Re: Compare zip lists where order is important (Frank Millman)
>   20. Re: [SOLVED] Re: Compare zip lists where order is important
>   (Sayth Renshaw)
>   21. Re: [SOLVED] Re: Compare zip lists where order is important
>   (Peter Otten)
>   22. Re: unable to to install paython (o1bigtenor)
>   23. Re: if STREAM.isatty(): (Rhodri James)
>   24. Re: if STREAM.isatty(): (Hongyi Zhao)
>   25. Re: if STREAM.isatty(): (Rhodri James)
>   26. Re: if STREAM.isatty(): (Eryk Sun)
>   27. Re: pandas loc on str lower for column comparison
>   (Piet van Oostrum)
>   28. Re: pandas loc on str lower for column comparison
>   (Piet van Oostrum)
>   29. Re: if STREAM.isatty(): (Hongyi Zhao)
>   30. Re: if STREAM.isatty(): (Rhodri James)
>   31. Re: unable to to install paython (Dennis Lee Bieber)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python unit test framework to fire 1000 unique concurrent requests

2019-08-28 Thread Pankaj Jangid
vishwatheworld...@gmail.com writes:

> Looking for a unit test framework with below requirements:
> 1. Send 1000 unique URL requests in parallel ( Not sequential and not 
> repetitive requests)
> 2. Verify HTTP response status code ( eg: 200, 403, 404 etc)  of each 
> requests in parallel
> 3. Verify Response headers of each URL requests
> 4. Login to remote machine ( to which requests is fired) and verify logs
>
1st is a load testing. You can use something like Apache JMeter. For
other advanced validations use Desktop version of vREST - 
https://desktop.vrest.io/.

Regards.

-- 
Pankaj Jangid
-- 
https://mail.python.org/mailman/listinfo/python-list


[issue29130] Exit code 120 returned from Python unit test testing SystemExit

2017-01-03 Thread R. David Murray

Changes by R. David Murray :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29130] Exit code 120 returned from Python unit test testing SystemExit

2017-01-03 Thread John Hagen

John Hagen added the comment:

I'm completely fine with closing this issue. Thanks for the help everyone.

If someone else doesn't close it in a couple days, I'll do it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29130] Exit code 120 returned from Python unit test testing SystemExit

2017-01-03 Thread STINNER Victor

STINNER Victor added the comment:

This issue is not a bug in Python, but a bug in the author's code. I suggest to 
close the issue, since enough clues have been provided to fix the author's 
issue.

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29130] Exit code 120 returned from Python unit test testing SystemExit

2017-01-02 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

> Having said all that, perhaps it would be reasonable to tolerate a missing 
> flush() method, and not treat this as an error.

In all cases the flush() method is called unconditionally. I think it can be 
considered as mandatory part of the writer protocol.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29130] Exit code 120 returned from Python unit test testing SystemExit

2017-01-02 Thread Martin Panter

Martin Panter added the comment:

David is right. The 120 code was added in Issue 5319, as a way of indicating a 
problem in the final stages of the interpreter exiting. The two conditions that 
trigger this are calling the flush() method on sys.stdout and sys.stderr. If 
you add a dummy flush() implementation, it no longer exits with 120:

>>> subprocess.call((sys.executable, "-c", """
... class NullWriter:
... def write(self, s): pass
... import sys; sys.stderr = NullWriter()"""))
120
>>> subprocess.call((sys.executable, "-c", """
... class NullWriter:
... def write(self, s): pass
... def flush(self): pass
... import sys; sys.stderr = NullWriter()"""))
0

It does not seem to be explicitly documented what you can set sys.stderr to, 
but I always thought it is safest to use an io.TextIOBase implementation. I 
would suggest to derive your NullWriter class from TextIOBase; that way you get 
a default flush() implementation for free.

Other options are to use StringIO() if you are not expecting too much output, 
or open(os.devnull, "w"). See also Issue 28864 about adding a predefined class 
like NullWriter to Python.

Having said all that, perhaps it would be reasonable to tolerate a missing 
flush() method, and not treat this as an error.

Stepping back a bit, I also suggest restoring sys.stderr after the test. 
Otherwise, you risk missing an error message. Try contextlib.redirect_stderr().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29130] Exit code 120 returned from Python unit test testing SystemExit

2017-01-02 Thread Xiang Zhang

Xiang Zhang added the comment:

Behaviour changed in #5319. Add author Martin.

--
nosy: +martin.panter, xiang.zhang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29130] Exit code 120 returned from Python unit test testing SystemExit

2017-01-01 Thread R. David Murray

R. David Murray added the comment:

My guess would be that the problem that your NullWriter doesn't have a flush 
method.  But I'm not familiar with this change, so I'm just guessing.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29130] Exit code 120 returned from Python unit test testing SystemExit

2017-01-01 Thread John Hagen

New submission from John Hagen:

I recently tried to port one of my packages to Python 3.6 and unit tests that 
worked in Python 2.7, 3.3-3.5 began failing in 3.6.

I originally thought it was a problem with coverage, but it turns out it was 
not. The full thread is: 
https://bitbucket.org/ned/coveragepy/issues/545/coverage-fails-on-python-36-travis-build

The highlight is this unit test causes Python to exit with status code 120 
(which fails a Travis build):

class ParseArgumentsTestCase(unittest.TestCase):
def test_no_arguments(self):  # type: () -> None
with self.assertRaises(SystemExit):
# Suppress argparse stderr.
class NullWriter:
def write(self, s):  # type: (str) -> None
pass

sys.stderr = NullWriter()
parse_arguments()

Ned found this corresponding note in the Python 3.6 release notes:

Changed in version 3.6: If an error occurs in the cleanup after the Python 
interpreter has caught SystemExit (such as an error flushing buffered data in 
the standard streams), the exit status is changed to 120.

If this is indeed, correct behavior and Python 3.6 is catching something 
incorrect (I agree this is not necessarily the most elegant unit test) then I 
am happy to close this issue. Just wanted to be sure I at least reported it in 
case this was a real issue.

--
components: IO
messages: 284437
nosy: John Hagen
priority: normal
severity: normal
status: open
title: Exit code 120 returned from Python unit test testing SystemExit
type: behavior
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29130>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: Python Unit test

2016-01-30 Thread 4ndre4

On 27/01/2016 04:57, toluagbo...@gmail.com wrote:
[...]

Here is what the python code looks like and I am to make a Unittest for it


Just a few ideas: first of all, you have to make your code more modular, 
for it to be unit-testable.


There are a few areas in your code that need testing:

- command line option usage/parsing/validation:
  - test that the parameters passed are syntactically correct
  - test that the parameters passed are semantically correct
  - test that the command line usage shown to the user is correct 
(based on the available options)


This might require the creation of a Usage class that encapsulate the 
usage of getopt. The class could validate the input command line, and 
return a string for the usage. As long as you have a Usage class, you 
can test its behaviours.


- filtering/decoding data:
  - test that a filter is correctly set
  - test that the data are correctly decoded

This might require the creation of a Filter and Decoder classes, the 
former encapsulating the behaviour of your 'pc'; the latter 
encapsulating your 'decode'. The dependency between these two classes 
can be mocked, for example. You can mock the data returned by 
pc.datalink() in your decoding code and make sure they are correctly 
decoded.


And so on...

--
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)

--
https://mail.python.org/mailman/listinfo/python-list


Re: Python Unit test

2016-01-28 Thread toluagboola
Thanks for the contributions. Took a while but I got the function done. My 
problem was in the first two lines, I had to import the python file in my test 
code which I did not do earlier
-- 
https://mail.python.org/mailman/listinfo/python-list


Python Unit test

2016-01-26 Thread toluagboola
I'm a University student of IT with majors in Embedded Systems. I have this 
assignment where I have to write Unittest for a simple Python Code without 
having prior knowledge of Python. I really need some help.
Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python Unit test

2016-01-26 Thread toluagboola
Yes I have studied the page but it's quite vague to me. So we have this project 
- Development of a touch screen controllable IEC61850 standard protocol 
analyzer. With this analyzer user can monitor and analyze network traffic in 
substation network.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python Unit test

2016-01-26 Thread toluagboola
On Tuesday, January 26, 2016 at 10:57:51 PM UTC+2, 4ndre4 wrote:
> On 26/01/2016 11:09, toluagbo...@gmail.com wrote:
> 
> [...]
> > I'm a University student of IT with majors in Embedded Systems.
>  > I have this assignment where I have to write Unittest for a simple 
> Python Code
>  > without having prior knowledge of Python. I really need some help.
> 
> www.python.org to get a basic grasp on Python. There is a very good 
> tutorial there.
> 
> As for unit testing, you need to know a bit of the the theory behind it, 
> and how to use it in Python.
> 
> The following are four very good books about unit testing, in general:
> 
> Effective Unit Testing: A guide for Java developers - Lasse Koskela
> Test Driven: TDD and Acceptance TDD for Java Developers - Lasse Koskela
> Test-Driven Development: By Example - Kent Beck
> 
> This is a good book but with examples in C# (you might just get the 
> logic behind them):
> The Art of Unit Testing: with examples in C# - Roy Osherove
> 
> I am pretty sure that on Amazon you can find many others about specific 
> unit testing in Python.
> 
> On YouTube, there's a good number of videos about unit testing.
> This one, for example: https://www.youtube.com/watch?v=TWBDa5dqrl8
> 
> -- 
> 4ndre4
> "The use of COBOL cripples the mind; its teaching should, therefore, be 
> regarded as a criminal offense." (E. Dijkstra)

import getopt, sys
import dpkt, pcap

def usage():
print >>sys.stderr, 'usage: %s [-i device] [pattern]' % sys.argv[0]
sys.exit(1)

def main():
opts, args = getopt.getopt(sys.argv[1:], 'i:h')
name = None
for o, a in opts:
if o == '-i': name = a
else: usage()

pc = pcap.pcap(name)
pc.setfilter(' '.join(args))
decode = { pcap.DLT_LOOP:dpkt.loopback.Loopback,
   pcap.DLT_NULL:dpkt.loopback.Loopback,
   pcap.DLT_EN10MB:dpkt.ethernet.Ethernet }[pc.datalink()]
try:
print 'listening on %s: %s' % (pc.name, pc.filter)
for ts, pkt in pc:
print ts, `decode(pkt)`
except KeyboardInterrupt:
nrecv, ndrop, nifdrop = pc.stats()
print '\n%d packets received by filter' % nrecv
print '%d packets dropped by kernel' % ndrop

if __name__ == '__main__':
main()


Here is what the python code looks like and I am to make a Unittest for it
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python Unit test

2016-01-26 Thread David Palao
Well, there is a very specific example in there.
But you still don't give us much information about *concrete* troubles you have.
I *guess* that one of the following is true:
1) You have problems to understand some part of the example in the
unittest module documentation.
2) You don't know how to apply those ideas to some specific code you have.
3) something else.
Could you please be more specific?

Best

2016-01-26 13:26 GMT+01:00  :
> Yes I have studied the page but it's quite vague to me. So we have this 
> project - Development of a touch screen controllable IEC61850 standard 
> protocol analyzer. With this analyzer user can monitor and analyze network 
> traffic in substation network.
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python Unit test

2016-01-26 Thread Bernardo Sulzbach
Or maybe he doesn't know enough about unit testing. If that is the
case, Wikipedia and SO should have you covered. Amazon has a few books
on the subject, too.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python Unit test

2016-01-26 Thread Tolu Agboola
I'll go with number 2. I don't know how to apply the ideas to the code I have. 

Sent from my iPhone

> On 26 Jan 2016, at 15:48, David Palao  wrote:
> 
> Well, there is a very specific example in there.
> But you still don't give us much information about *concrete* troubles you 
> have.
> I *guess* that one of the following is true:
> 1) You have problems to understand some part of the example in the
> unittest module documentation.
> 2) You don't know how to apply those ideas to some specific code you have.
> 3) something else.
> Could you please be more specific?
> 
> Best
> 
> 2016-01-26 13:26 GMT+01:00  :
>> Yes I have studied the page but it's quite vague to me. So we have this 
>> project - Development of a touch screen controllable IEC61850 standard 
>> protocol analyzer. With this analyzer user can monitor and analyze network 
>> traffic in substation network.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python Unit test

2016-01-26 Thread Joel Goldstick
On Tue, Jan 26, 2016 at 10:48 AM, Tolu Agboola 
wrote:

> I'll go with number 2. I don't know how to apply the ideas to the code I
> have.
>
> Sent from my iPhone
>
> > On 26 Jan 2016, at 15:48, David Palao  wrote:
> >
> > Well, there is a very specific example in there.
> > But you still don't give us much information about *concrete* troubles
> you have.
> > I *guess* that one of the following is true:
> > 1) You have problems to understand some part of the example in the
> > unittest module documentation.
> > 2) You don't know how to apply those ideas to some specific code you
> have.
> > 3) something else.
> > Could you please be more specific?
> >
> > Best
> >
> > 2016-01-26 13:26 GMT+01:00  :
> >> Yes I have studied the page but it's quite vague to me. So we have this
> project - Development of a touch screen controllable IEC61850 standard
> protocol analyzer. With this analyzer user can monitor and analyze network
> traffic in substation network.
> >> --
> >> https://mail.python.org/mailman/listinfo/python-list
> --
> https://mail.python.org/mailman/listinfo/python-list
>

Test driven development with python and django.  The complete text is
online here:
http://chimera.labs.oreilly.com/books/123400754/pr02.html#_python_3_and_programming


-- 
Joel Goldstick
http://joelgoldstick.com/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python Unit test

2016-01-26 Thread David Palao
2016-01-26 16:56 GMT+01:00 Joel Goldstick :
> On Tue, Jan 26, 2016 at 10:48 AM, Tolu Agboola 
> wrote:
>
>> I'll go with number 2. I don't know how to apply the ideas to the code I
>> have.
>>
>> Sent from my iPhone
>>
>> > On 26 Jan 2016, at 15:48, David Palao  wrote:
>> >
>> > Well, there is a very specific example in there.
>> > But you still don't give us much information about *concrete* troubles
>> you have.
>> > I *guess* that one of the following is true:
>> > 1) You have problems to understand some part of the example in the
>> > unittest module documentation.
>> > 2) You don't know how to apply those ideas to some specific code you
>> have.
>> > 3) something else.
>> > Could you please be more specific?
>> >
>> > Best
>> >
>> > 2016-01-26 13:26 GMT+01:00  :
>> >> Yes I have studied the page but it's quite vague to me. So we have this
>> project - Development of a touch screen controllable IEC61850 standard
>> protocol analyzer. With this analyzer user can monitor and analyze network
>> traffic in substation network.
>> >> --
>> >> https://mail.python.org/mailman/listinfo/python-list
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
> Test driven development with python and django.  The complete text is
> online here:
> http://chimera.labs.oreilly.com/books/123400754/pr02.html#_python_3_and_programming
>
>
> --
> Joel Goldstick
> http://joelgoldstick.com/stats/birthdays
> --
> https://mail.python.org/mailman/listinfo/python-list

Good reference.
I like also this one:
http://code.tutsplus.com/tutorials/test-driven-development-in-python--net-30137
which is shorter.

Best
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python Unit test

2016-01-26 Thread 4ndre4

On 26/01/2016 11:09, toluagbo...@gmail.com wrote:

[...]

I'm a University student of IT with majors in Embedded Systems.
> I have this assignment where I have to write Unittest for a simple 
Python Code

> without having prior knowledge of Python. I really need some help.

www.python.org to get a basic grasp on Python. There is a very good 
tutorial there.


As for unit testing, you need to know a bit of the the theory behind it, 
and how to use it in Python.


The following are four very good books about unit testing, in general:

Effective Unit Testing: A guide for Java developers - Lasse Koskela
Test Driven: TDD and Acceptance TDD for Java Developers - Lasse Koskela
Test-Driven Development: By Example - Kent Beck

This is a good book but with examples in C# (you might just get the 
logic behind them):

The Art of Unit Testing: with examples in C# - Roy Osherove

I am pretty sure that on Amazon you can find many others about specific 
unit testing in Python.


On YouTube, there's a good number of videos about unit testing.
This one, for example: https://www.youtube.com/watch?v=TWBDa5dqrl8

--
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)


--
https://mail.python.org/mailman/listinfo/python-list


Re: Python Unit test

2016-01-26 Thread David Palao
Hello,
It would be good to provide more details on what you need help for.
For instance, have you read the manual
https://docs.python.org/3/library/unittest.html
?
It even contains a couple of examples.

Best

2016-01-26 12:09 GMT+01:00  :
> I'm a University student of IT with majors in Embedded Systems. I have this 
> assignment where I have to write Unittest for a simple Python Code without 
> having prior knowledge of Python. I really need some help.
> Thanks
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Fwd: python unit test framework sample code

2016-01-11 Thread Ganesh Pal
Totally stuck with this
On Jan 10, 2016 7:11 PM, "Ganesh Pal" <ganesh1...@gmail.com> wrote:

> Apologies,  looks like I did a reply instead of reply-all. So
> forwarding this email , please provide guidance on the same
>
> -- Forwarded message --
> From: Ganesh Pal <ganesh1...@gmail.com>
> Date: Thu, Jan 7, 2016 at 12:26 PM
> Subject: Re: python unit test framework sample code
> To: Terry Reedy <tjre...@udel.edu>
>
> > Unless you have a large program already in 2.6 and are just adding tests
> > (perhaps so you can more easily upgrade someday), consider upgrading to a
> > newer version.
>
> Sure , but for now Iam limited to use 2.6 , hence I cant upgrade need
> to work with 2.6
>
> >>
> >> class FileSystemTest(unittest2.TestCase):
> >>  block_address = {}
> >>  report = ""
> >>
> >>  @classmethod
> >>  def setUpClass(cls):
> >>  cls.FileSystemSetup()
> >
> >
> > This is senseless.  Put the body of FileSystemSetup here.
>
> I didn't understand  which line is senseless. I was trying to refer
> this example on stack overflow
>
> http://stackoverflow.com/questions/5938517/not-able-call-a-local-method-from-setupclass
>
>
> class TestSystemPromotion(unittest2.TestCase):
>
>   @classmethod
>   def setUpClass(cls):
> cls.setup_test_data()
>
>
>   @classmethod
>   def setup_test_data(cls):
> ...
>
>   def test_something(self):
> ...
>
>
> class FileSystemTest(unittest2.TestCase):
> block_address = {}
> report = ""
>
> @classmethod
> def setUpClass(cls):
> cls.FileSystemSetup()
>
> @classmethod
> def FileSystemSetup(cls):
> """
> Initial setup before unittest is run
> """
> logging.info("SETUP.Started !!!")
>
> >>  def inode_corruption(self):
> >>  """ test_01: inode  corruption """
> >>  self.assertTrue(corrupt.run_query_tool(self.__class__.report,
> >
> >
> > self.block_address['test_01']))
> >
> > Assuming that unittest2 is same as unittest, test methods must be called
> > test_xyz.  So this is not run, hence no error.
>
> Sorry  I have changed this from inode_corruption' to 'test_inode_corruption
>
> >
> >>  @classmethod
> >>  def tearDownClass(cls):
> >>  cls.tearDown()
> >
> >
> > Ditto.  Put real body here.
> >
> >>  @classmethod
> >>  def tearDown(cls):
> >
> >
>
> > The above refers to functions you did not post.  For current unittest, it
> > looks likes you should be using a setUpModule (possible tearDownModule)
> > functions, but I don't know if those are available in the older
> unittest2.
>
>
> we have tearDownClass and setUpClass in python 2.6 and under unittest2
>
> >>> help(unittest2.TestCase.tearDownClass)
> Help on method tearDownClass in module unittest2.case:
>
> tearDownClass(cls) method of __builtin__.type instance
> Hook method for deconstructing the class fixture after running all
> tests in the class.
>
> >>> help(unittest2.TestCase.setUpClass)
> Help on method setUpClass in module unittest2.case:
>
> setUpClass(cls) method of __builtin__.type instance
> Hook method for setting up class fixture before running tests in the
> class.
>
> Regards,
> Ganesh
>
-- 
https://mail.python.org/mailman/listinfo/python-list


Fwd: python unit test framework sample code

2016-01-10 Thread Ganesh Pal
Apologies,  looks like I did a reply instead of reply-all. So
forwarding this email , please provide guidance on the same

-- Forwarded message --
From: Ganesh Pal <ganesh1...@gmail.com>
Date: Thu, Jan 7, 2016 at 12:26 PM
Subject: Re: python unit test framework sample code
To: Terry Reedy <tjre...@udel.edu>

> Unless you have a large program already in 2.6 and are just adding tests
> (perhaps so you can more easily upgrade someday), consider upgrading to a
> newer version.

Sure , but for now Iam limited to use 2.6 , hence I cant upgrade need
to work with 2.6

>>
>> class FileSystemTest(unittest2.TestCase):
>>  block_address = {}
>>  report = ""
>>
>>  @classmethod
>>  def setUpClass(cls):
>>  cls.FileSystemSetup()
>
>
> This is senseless.  Put the body of FileSystemSetup here.

I didn't understand  which line is senseless. I was trying to refer
this example on stack overflow
http://stackoverflow.com/questions/5938517/not-able-call-a-local-method-from-setupclass


class TestSystemPromotion(unittest2.TestCase):

  @classmethod
  def setUpClass(cls):
cls.setup_test_data()


  @classmethod
  def setup_test_data(cls):
...

  def test_something(self):
...


class FileSystemTest(unittest2.TestCase):
block_address = {}
report = ""

@classmethod
def setUpClass(cls):
cls.FileSystemSetup()

@classmethod
def FileSystemSetup(cls):
"""
Initial setup before unittest is run
"""
logging.info("SETUP.Started !!!")

>>  def inode_corruption(self):
>>  """ test_01: inode  corruption """
>>  self.assertTrue(corrupt.run_query_tool(self.__class__.report,
>
>
> self.block_address['test_01']))
>
> Assuming that unittest2 is same as unittest, test methods must be called
> test_xyz.  So this is not run, hence no error.

Sorry  I have changed this from inode_corruption' to 'test_inode_corruption

>
>>  @classmethod
>>  def tearDownClass(cls):
>>  cls.tearDown()
>
>
> Ditto.  Put real body here.
>
>>  @classmethod
>>  def tearDown(cls):
>
>

> The above refers to functions you did not post.  For current unittest, it
> looks likes you should be using a setUpModule (possible tearDownModule)
> functions, but I don't know if those are available in the older unittest2.


we have tearDownClass and setUpClass in python 2.6 and under unittest2

>>> help(unittest2.TestCase.tearDownClass)
Help on method tearDownClass in module unittest2.case:

tearDownClass(cls) method of __builtin__.type instance
Hook method for deconstructing the class fixture after running all
tests in the class.

>>> help(unittest2.TestCase.setUpClass)
Help on method setUpClass in module unittest2.case:

setUpClass(cls) method of __builtin__.type instance
Hook method for setting up class fixture before running tests in the class.

Regards,
Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list


python unit test framework sample code

2016-01-06 Thread Ganesh Pal
Hello Team,

I have written a small program using python unit test framework . I
need your guidance to find out

1. If I have used the fixtures and classes properly ( first oop program) :) )
2. why does unittest2.SkipTest not print the message when the failures
are encountered  ?
3. Also sys.stderr.write("Test run failed ({e})".format(e=e) ) does
not display error on failure ?
4. Any other general comment's

Iam on Python 2.6 and using Linux

Sample code:

class FileSystemTest(unittest2.TestCase):
block_address = {}
report = ""

@classmethod
def setUpClass(cls):
cls.FileSystemSetup()

@classmethod
def FileSystemSetup(cls):
"""
Initial setup before unittest is run
"""
logging.info("SETUP.Started !!!")
try:
inode_01 =
corrupt.get_lin(os.path.join(CORRUPT_DIR,"inode_lin.txt"))
test_01_log = os.path.join(LOG_DIR, "test_01_corrupt.log")
cls.block_address['test_01'] =
corrupt.inject_corruption(test_01_log,
lin=inode_01, object="inode", offset="18",
size="4", optype="set")
time.sleep(10)

except Exception, e:
logging.error(e)
raise unittest2.SkipTest("class setup failed")
if not corrupt.run_scanner():
   raise unittest2.SkipTest("class setup failed")

else:
 try:
 cls.report = corrupt.run_report()
 except Exception, e:
logging.error(e)
raise unittest2.SkipTest("class setup failed")
logging.info("SETUP.Done !!!")

def inode_corruption(self):
""" test_01: inode  corruption """
self.assertTrue(corrupt.run_query_tool(self.__class__.report,
 self.block_address['test_01']))
@classmethod
def tearDownClass(cls):
cls.tearDown()

@classmethod
def tearDown(cls):
print "Entered tearDown()"
try:
cls.cleanup = cleanup()
except Exception, e:
  logging.error(e)

def main():
""" ---MAIN--- """
global LOG_DIR
try:
if len(sys.argv) > 1:
LOG_DIR = str(sys.argv[1])
except Exception, e:
print(USAGE)
return errno.EINVAL
functions = [create_logdir,create_dataset,corrupt.prep_cluster]
for func in functions:
try:
func()
except Exception, e:
logging.error(e)
sys.stderr.write("Test run failed ({e})".format(e=e))
unittest2.main()

if __name__ == '__main__':
main()


PS : Happy  New year Wishes to all the form members !!

Regards,
Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python unit test framework sample code

2016-01-06 Thread Terry Reedy

On 1/6/2016 8:45 AM, Ganesh Pal wrote:

Hello Team,

I have written a small program using python unit test framework . I
need your guidance to find out

1. If I have used the fixtures and classes properly ( first oop program) :) )
2. why does unittest2.SkipTest not print the message when the failures
are encountered  ?
3. Also sys.stderr.write("Test run failed ({e})".format(e=e) ) does
not display error on failure ?
4. Any other general comment's

I am on Python 2.6 and using Linux


Unless you have a large program already in 2.6 and are just adding tests 
(perhaps so you can more easily upgrade someday), consider upgrading to 
a newer version.



Sample code:

class FileSystemTest(unittest2.TestCase):
 block_address = {}
 report = ""

 @classmethod
 def setUpClass(cls):
 cls.FileSystemSetup()


This is senseless.  Put the body of FileSystemSetup here.


 @classmethod
 def FileSystemSetup(cls):
 """
 Initial setup before unittest is run
 """
 logging.info("SETUP.Started !!!")
 try:
 inode_01 =
corrupt.get_lin(os.path.join(CORRUPT_DIR,"inode_lin.txt"))
 test_01_log = os.path.join(LOG_DIR, "test_01_corrupt.log")
 cls.block_address['test_01'] =
corrupt.inject_corruption(test_01_log,
 lin=inode_01, object="inode", offset="18",
size="4", optype="set")
 time.sleep(10)

 except Exception, e:
 logging.error(e)
 raise unittest2.SkipTest("class setup failed")
 if not corrupt.run_scanner():
raise unittest2.SkipTest("class setup failed")

 else:
  try:
  cls.report = corrupt.run_report()
  except Exception, e:
 logging.error(e)
 raise unittest2.SkipTest("class setup failed")
 logging.info("SETUP.Done !!!")

 def inode_corruption(self):
 """ test_01: inode  corruption """
 self.assertTrue(corrupt.run_query_tool(self.__class__.report,


self.block_address['test_01']))

Assuming that unittest2 is same as unittest, test methods must be called 
test_xyz.  So this is not run, hence no error.




 @classmethod
 def tearDownClass(cls):
 cls.tearDown()


Ditto.  Put real body here.


 @classmethod
 def tearDown(cls):


This is worse than setup.  The name 'tearDown' is reserved for and 
called to teardown after each test_xyz method is called.  So once you 
change 'inode'corruption' to 'test_inode_corruption', this should fail.



 print "Entered tearDown()"
 try:
 cls.cleanup = cleanup()
 except Exception, e:
   logging.error(e)

def main():
 """ ---MAIN--- """
 global LOG_DIR
 try:
 if len(sys.argv) > 1:
 LOG_DIR = str(sys.argv[1])
 except Exception, e:
 print(USAGE)
 return errno.EINVAL
 functions = [create_logdir,create_dataset,corrupt.prep_cluster]
 for func in functions:
 try:
 func()
 except Exception, e:
 logging.error(e)
 sys.stderr.write("Test run failed ({e})".format(e=e))


The above refers to functions you did not post.  For current unittest, 
it looks likes you should be using a setUpModule (possible 
tearDownModule) functions, but I don't know if those are available in 
the older unittest2.



 unittest2.main()

if __name__ == '__main__':
 main()


I think the biggest mistake people make is to do too much new stuff at 
once.  Python, with IDLE (or equivalent), makes incremental development 
easy.  My first unittest program was about 10 lines.  I expanded from 
there.  I am still 'expanding' from my current knowledge.



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list


Re: python unit test frame work

2015-12-12 Thread Ganesh Pal
On Thu, Dec 10, 2015 at 9:20 PM, Peter Otten <__pete...@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

==
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)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python unit test frame work

2015-12-12 Thread Peter Otten
Ganesh Pal wrote:

> On Thu, Dec 10, 2015 at 9:20 PM, Peter Otten <__pete...@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
> 
> ==
> 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.

-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python unit test frame work

2015-12-10 Thread Ganesh Pal
+python list .  sorry I accidentally did a reply to Peter.

On Dec 11, 2015 3:57 AM, "Ganesh Pal"  wrote:
>
>
> > Drop the habit to sprinkle sys.exit() all over the place. A well-behaved
> > application has one exit point, at the end of the main module.
>
I was using sys.exit() as the means to stop the  execution or terminate the
program. I can't think of an alternative for my case :
I have multiple checks if I don't meet them continuing with the main
program doesn't make sense

Regards,
Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python unit test frame work

2015-12-10 Thread Ben Finney
Ganesh Pal  writes:

> I have multiple checks if I don't meet them continuing with the main
> program doesn't make sense

That means these are not unit tests (which are isolatable, independent
test cases).

If the tests are best characterised as a sequence of steps, then the
‘unittest’ model (designed for actual unit tests) will not fit well.

You should instead just write a ‘main’ function that calls each test
case in turn and exits when one of them fails.

import sys

from .. import foo_app


def test_input_wibble_returns_lorem(frob):
""" Should process 'wibble' input and result in state 'lorem'. """
frob.process("wibble")
if frob.state != "lorem":
raise AssertionError


def test_input_warble_returns_ipsum():
""" Should process warble' input and result in state 'ipsum'. """
frob.process("warble")
if frob.state != "ipsum":
raise AssertionError


# …

EXIT_STATUS_ERROR = 1

def main(argv):
""" Mainline code for this module. """

process_args(argv)

test_cases = [
test_input_wibble_returns_lorem,
test_input_warble_returns_ipsum,
# …
]

test_frob = foo_app.Frob()

for test_case in test_cases:
try:
test_case(test_frob)
except AssertionError as exc:
sys.stderr.write("Test run failed ({exc})".format(exc=exc))
sys.exit(EXIT_STATUS_ERROR)


if __name__ == "__main__":
exit_status = main(sys.argv)
sys.exit(exit_status)

-- 
 \“The greatest tragedy in mankind's entire history may be the |
  `\   hijacking of morality by religion.” —Arthur C. Clarke, 1991 |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python unit test frame work

2015-12-10 Thread Cameron Simpson

On 11Dec2015 04:05, Ganesh Pal  wrote:

On Dec 11, 2015 3:57 AM, "Ganesh Pal"  wrote:

> Drop the habit to sprinkle sys.exit() all over the place. A well-behaved
> application has one exit point, at the end of the main module.


I was using sys.exit() as the means to stop the  execution or terminate the
program. I can't think of an alternative for my case :
I have multiple checks if I don't meet them continuing with the main
program doesn't make sense


First, as Ben remarks, if one test _depends_ on an earlier one then it isn't a 
real unit test.


On the other hand, if you simply have some simple tests followed by more 
complex tests (I have several like this) you have two facilities to help you.  

Firstly, I have observed that unittest tends to run tests in lexical order, so 
I tend to name the test methods like this:


 def test00minimalist(self):
 def test01minimalPlusOneThing(self):
 ...
 def test20somethingComplex(self):

and on the command line when you are hand testing things:

 python -m cs.venti.tcp_tests -v -f

Of course, substitute your module name. The -v recites the test names and 
docstring first line as Peter has mentioned. The -f causes the etst suit to 
fail on the first test failure, and does not run the later tests. That seems to 
cover what you want here: abort on the simplest failing test.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list


Re: python unit test frame work

2015-12-10 Thread Ben Finney
Cameron Simpson  writes:

> First, as Ben remarks, if one test _depends_ on an earlier one then it
> isn't a real unit test.
>
> On the other hand, if you simply have some simple tests followed by
> more complex tests (I have several like this) you have two facilities
> to help you.
>
> Firstly, I have observed that unittest tends to run tests in lexical
> order

Back on the first hand again, some unit test runners will deliberately
*change* the order so your test cases are tested for independence.

Really, if your test cases depend on being executed in a particular
sequence, the ‘unittest’ module is a poor fit.

-- 
 \   “Come on, if your religion is so vulnerable that a little bit |
  `\   of disrespect is going to bring it down, it's not worth |
_o__)   believing in, frankly.” —Terry Gilliam, 2005-01-18 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python unit test frame work

2015-12-10 Thread Cameron Simpson

On 11Dec2015 14:09, Ben Finney  wrote:

Cameron Simpson  writes:

First, as Ben remarks, if one test _depends_ on an earlier one then it
isn't a real unit test.

On the other hand, if you simply have some simple tests followed by
more complex tests (I have several like this) you have two facilities
to help you.

Firstly, I have observed that unittest tends to run tests in lexical
order


Back on the first hand again, some unit test runners will deliberately
*change* the order so your test cases are tested for independence.


That's fine. My tests are independent. But it is _handy_ that while building 
the tests and adding new tests that they are issued in a predictable order.



Really, if your test cases depend on being executed in a particular
sequence, the ‘unittest’ module is a poor fit.


Yes, but that is not the case for me, and quite possibly for the OP. Even if 
they aren't, he seems savvy and quick to learn and willing to adjust worse 
practice for better.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list


Re: python unit test frame work

2015-12-10 Thread Peter Otten
Ganesh Pal wrote:

> Hello Team,
> 
> Iam on python 2.7 and linux.  Iam trying to understand the python unit
> test frame work and also trying to fix the below code , any help in
> this regard would be appreciated ?

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.

If a necessary ressource cannot be acquired you can raise a SkipTest 
exception and the test or tests will not run.

> logging.info("### Executing test01: inode corruption ###")

In --verbose mode unittest will print the first line of the test methods' 
docstring. That should be sufficient most of the time.

Only loosely related:

Drop the habit to sprinkle sys.exit() all over the place. A well-behaved 
application has one exit point, at the end of the main module.

> self.__class__.report

When reading the report attribute this is the same as just

self.report

(unless you shaded it in the instance). 

> # Sample code starts here
> inject_failure = {}
> report = ""
> ClassIsSetup = False
> ClassCleanup = False
> 
> class Test_filesystem(unittest.TestCase):
>   """ """
>   def TestSetup(self):
> """ Initial setup before unittests run  """
> logging.info("SETUP.Started !!!")
> if not os.path.ismount("/tmp"):  # Comment 1.
>logging.error("Error: /tmp is not mounted")
>sys.exit("/tmp is not mounted ...Exiting !!!")
> 
> if self.create_dataset() and capture_chksum():
>try:
>test01_log = os.path.join(LOG_DIR, "test01_corrupt.log")
>self.inject_failure['test01'] = tool.run_tool(test01_log)
>time.sleep(10)
>test02_log = os.path.join(LOG_DIR, "test01_corrupt.log")
>self.inject_failure['test01'] = tool.run_tool(test02_log)
>time.sleep(10)
>except Exception, e:
>   logging.error(e)
>   sys.exit(1)
> if not run_scanner():
>sys.exit(1)
> else:
>  try:
>  self.__class__.report = report_tool()
>  except Exception, e:
> logging.error(e)
> sys.exit("Running Reporting tool failed")
> logging.info("SETUP.Done !!!")
> 
> def setUp(self):
> if not self.ClassIsSetup:
> self.__class__.ClassIsSetup = True
> self.setupClass()
> 
> def setupClass(self):
> self.TestSetup()
> 
> def test_01_inode_test(self):
> """  test01: """
> logging.info("### Executing test01: inode corruption ###")
> self.assertTrue(run_db_tool(self.__class__.report,
>
self.find_failure['test01']))
> def test_02_hardlink_test(self):
> """  test02: """
> logging.info("### Executing test01: inode corruption ###")
> self.assertTrue(run_db_tool(self.__class__.report,
> 
> def tearDown(self):
> if self.ClassCleanup:
> self.tearDownClass()
> 
> def tearDownClass(self):
> self.cleanup()
> 
> # Comment 2
> def cleanup(self):
> """ Cleanup all the data & logs """
> logging.info("Cleaning all data")
> os.system("rm -rf /tmp/data_set")
> 
> def main():
> unittest.main()
> 
> if __name__ == '__main__':
>   main()
> 
> # Sample code ends here
> 
> Questions :
> 
> 1. If the setUp() fails the code still tries to run through the test
> and  assert's with error.  How do I avoid these Error on the console ,
> actually test01, test02, . etc , shouldn't run if the setup Failed ?
> 
> Example: If the  mount fails i.e  if not os.path.ismount("/tmp"): in
> TestSetup(). we will get the below output:
> 
> #c_t.py
> 
> ==
> 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
> 

python unit test frame work

2015-12-10 Thread Ganesh Pal
Hello Team,

Iam on python 2.7 and linux.  Iam trying to understand the python unit
test frame work and also trying to fix the below code , any help in
this regard would be appreciated ?

# Sample code starts here
inject_failure = {}
report = ""
ClassIsSetup = False
ClassCleanup = False

class Test_filesystem(unittest.TestCase):
  """ """
  def TestSetup(self):
""" Initial setup before unittests run  """
logging.info("SETUP.Started !!!")
if not os.path.ismount("/tmp"):  # Comment 1.
   logging.error("Error: /tmp is not mounted")
   sys.exit("/tmp is not mounted ...Exiting !!!")

if self.create_dataset() and capture_chksum():
   try:
   test01_log = os.path.join(LOG_DIR, "test01_corrupt.log")
   self.inject_failure['test01'] = tool.run_tool(test01_log)
   time.sleep(10)
   test02_log = os.path.join(LOG_DIR, "test01_corrupt.log")
   self.inject_failure['test01'] = tool.run_tool(test02_log)
   time.sleep(10)
   except Exception, e:
  logging.error(e)
  sys.exit(1)
if not run_scanner():
   sys.exit(1)
else:
 try:
 self.__class__.report = report_tool()
 except Exception, e:
logging.error(e)
sys.exit("Running Reporting tool failed")
logging.info("SETUP.Done !!!")

def setUp(self):
if not self.ClassIsSetup:
self.__class__.ClassIsSetup = True
self.setupClass()

def setupClass(self):
self.TestSetup()

def test_01_inode_test(self):
"""  test01: """
logging.info("### Executing test01: inode corruption ###")
self.assertTrue(run_db_tool(self.__class__.report,
   self.find_failure['test01']))
def test_02_hardlink_test(self):
"""  test02: """
logging.info("### Executing test01: inode corruption ###")
self.assertTrue(run_db_tool(self.__class__.report,

def tearDown(self):
if self.ClassCleanup:
self.tearDownClass()

def tearDownClass(self):
self.cleanup()

# Comment 2
def cleanup(self):
""" Cleanup all the data & logs """
logging.info("Cleaning all data")
os.system("rm -rf /tmp/data_set")

def main():
unittest.main()

if __name__ == '__main__':
  main()

# Sample code ends here

Questions :

1. If the setUp() fails the code still tries to run through the test
and  assert's with error.  How do I avoid these Error on the console ,
actually test01, test02, . etc , shouldn't run if the setup Failed ?

Example: If the  mount fails i.e  if not os.path.ismount("/tmp"): in
TestSetup(). we will get the below output:

#c_t.py

==
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)

2. The cleanup() never gets executed at the end of the test.
3. Any better idea or suggestions to improve the above code ?

Regards,
Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list