Re: Art of Unit Testing

I had tested the above only with Python 2.4 but I just noticed it does not work with Python 2.3. The following works also with Python 2.3: import unittest class MyTestCase(unittest.TestCase): def setUp(self): print "setUp", def tearDown(self): print "tearDown", d

Re: Art of Unit Testing

"Terry Reedy" <[EMAIL PROTECTED]> writes: > "Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message > news:[EMAIL PROTECTED] >> I knew there was some other one before unittest came along but I thought >> unittest was supposed to replace the older stuff. > > I believe unittest was an altern

Re: Art of Unit Testing

> Your own feature request for setUpOnce() and tearDownOnce() is > trivially coded using a global or class variable to restrict running to > a single occasion. If that seems unpleasant, then encapsulate the > logic in a subclass of TestCase, in a decorator, or in a metaclass. Ok, you can have a s

Re: Art of Unit Testing

"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message news:[EMAIL PROTECTED] > I knew there was some other one before unittest came along but I thought > unittest was supposed to replace the older stuff. I believe unittest was an alternative rather than replacement for doctest. > What'

Re: Art of Unit Testing

Benjamin Niemann <[EMAIL PROTECTED]> writes: > Some (many?) people don't like the unittest module, because it is not very > pythonic - nothing to wonder as it has its root in the Java world. That's > probably one of the reasons why there are other (more pythonic) unittesting > frameworks for Python

Re: Art of Unit Testing

Christoph Zwerschke wrote: > I wasn't aware of the py lib so far. The > possibility to create fixtures at the three different scopes is exactly > what I was looking for. > > Anyway, I think it would be nice to have that feature in the standard > lib unittest as well. It should not be too hard to ad

RE: Art of Unit Testing

phil hunt wrote: >> tests? If they were unit tests, they should take only a few minutes >> to run, total, > > Eek! Seconds, more like. Unfortunately, when you've got umteen zillion of them, having individually fast test suites doesn't help much :( The complete test suite for my current project

Re: Art of Unit Testing

Michael Hoffman wrote: > Benjamin Niemann wrote: >> Christoph Zwerschke wrote: >> >> >>>Benjamin Niemann wrote: >>> Some (many?) people don't like the unittest module, because it is not very pythonic - nothing to wonder as it has its root in the Java world. That's probably one of the

Re: Art of Unit Testing

phil hunt wrote: > I think we might be talking at cross purposes here. To me > "acceptance test suite" means a test suite that has to be passed > each time before a new version of the software is released to the > users. I don't see that 10 minutes is a sensible limit here, unless > you are rel

Re: Art of Unit Testing

Christoph Zwerschke wrote: >>> - unittest is for *unit* testing (only) ;-) >> >> Why would you say that? We've used it extensively for a wide ranging... > > That was actually only a quote from this thread that summarizes some of > the answers I got: unittest has no support for "global" fixtures,

Re: Art of Unit Testing

Benjamin Niemann wrote: > Christoph Zwerschke wrote: > > >>Benjamin Niemann wrote: >> >>>Some (many?) people don't like the unittest module, because it is not >>>very pythonic - nothing to wonder as it has its root in the Java world. >>>That's probably one of the reasons why there are other (more

Re: Art of Unit Testing

>> - unittest is for *unit* testing (only) ;-) > Why would you say that? We've used it extensively for a wide ranging... That was actually only a quote from this thread that summarizes some of the answers I got: unittest has no support for "global" fixtures, because it is intended for unit test

Re: Art of Unit Testing

On Wed, 03 Aug 2005 09:51:49 -0400, Peter Hansen <[EMAIL PROTECTED]> wrote: >phil hunt wrote: >> On Tue, 02 Aug 2005 21:26:28 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> >> wrote: >>>According to the "extreme programming" paradigm, testing should be done >>>several times a day. So a requiremen

Re: Art of Unit Testing (Acceptance Tests)

"Christoph Zwerschke" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Peter Hansen wrote: >> What's wrong with using Python's existing "global" support, and just >> having your test case setUp() call a global setup routine which checks >> whether that global setup work has already

Re: Art of Unit Testing

phil hunt wrote: > On Tue, 02 Aug 2005 21:26:28 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> > wrote: >>According to the "extreme programming" paradigm, testing should be done >>several times a day. So a requirement for extreme programm is that tests >>are fast enough. If the testing needs too

Re: Art of Unit Testing

Christoph Zwerschke wrote: > I think wanting to have a more global initialization > indicates that you are acutally not wanting to do a "unit" test, but a > more global test of the overall system, something like an acceptance or > integration test, i.e. you are trying to abuse unittest for somet

Re: Art of Unit Testing

Christoph Zwerschke wrote: > - unittest is for *unit* testing (only) ;-) Why would you say that? We've used it extensively for a wide ranging of testing, not limited to unit tests. > - use mock objects to mimic the behaviour of external components like > databases ...when doing unit testing.

Re: Art of Unit Testing

On Tue, 02 Aug 2005 17:18:51 -0400, Peter Hansen <[EMAIL PROTECTED]> wrote: > >If you're going to quote XP rules of thumb, the tests should be >independent and very fast, and if you have a setup code that is taking a >long time, it's likely a "code smell" of some kind, and you should be >fixing

Re: Art of Unit Testing

On Wed, 03 Aug 2005 10:19:05 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: >rafi wrote: >> 'should' may be too strong, 'may' may be better. In the meantime I found: >> http://python-mock.sourceforge.net/ > >Thanks for the link. Björn also pointed to http://pmock.sourceforge.net > >Usin

Re: Art of Unit Testing

On Tue, 02 Aug 2005 18:44:01 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: >In August 2001, there was a thread about the "Art of Unit Testing": >http://groups.google.com/group/comp.lang.python/browse_frm/thread/aa2bd17e7f995d05/71a29faf0a0485d5 > >Paul Moore asked the legitimate question w

Re: Art of Unit Testing

On Wed, 03 Aug 2005 09:35:08 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > >> Some (many?) people don't like the unittest module, because it is not very >> pythonic - nothing to wonder as it has its root in the Java world. That's >> probably one of the reasons why there are other (more p

Re: Art of Unit Testing

On Tue, 02 Aug 2005 23:13:08 +0200, rafi <[EMAIL PROTECTED]> wrote: > >> According to the "extreme programming" paradigm, testing should be done >> several times a day. So a requirement for extreme programm is that tests >> are fast enough. If the testing needs too much time, people are >> disco

Re: Art of Unit Testing

On Tue, 02 Aug 2005 21:26:28 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: >Björn Lindström wrote: >>>Would it make sense to add "globaleSetup" and "globalTearDown" methods >>>to the TestCase class? >> In general that's not such a good idea. > >I completely agree and I think it makes a lot

Re: Art of Unit Testing

On Tue, 02 Aug 2005 19:02:09 +0200, Björn Lindström <[EMAIL PROTECTED]> wrote: >Christoph Zwerschke <[EMAIL PROTECTED]> writes: > >> Would it make sense to add "globaleSetup" and "globalTearDown" methods >> to the TestCase class? I think at least it would not harm >> anybody. Where should such prop

Re: Art of Unit Testing

On Tue, 02 Aug 2005 21:11:52 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: >Thanks for the link, Grig. I wasn't aware of the py lib so far. The >possibility to create fixtures at the three different scopes is exactly >what I was looking for. > >Anyway, I think it would be nice to have th

Re: Art of Unit Testing

rafi wrote: > 'should' may be too strong, 'may' may be better. In the meantime I found: > http://python-mock.sourceforge.net/ Thanks for the link. Björn also pointed to http://pmock.sourceforge.net Using mock objects sounds like a good idea. A problem with mock objects may be that they make

Re: Art of Unit Testing

Christoph Zwerschke wrote: > Benjamin Niemann wrote: >> Some (many?) people don't like the unittest module, because it is not >> very pythonic - nothing to wonder as it has its root in the Java world. >> That's probably one of the reasons why there are other (more pythonic) >> unittesting framewor

Re: Art of Unit Testing

Peter Hansen wrote: > What's wrong with using Python's existing "global" support, and just > having your test case setUp() call a global setup routine which checks > whether that global setup work has already been done and, if not, does > it once and sets a flag to say that it has now been done?

Re: Art of Unit Testing

Benjamin Niemann wrote: > The unittest module is a 'port' of the JUnit framework for Java which has a > certain wellknown API and semantics. The same API is available for many > other languages, so it is probably a good idea to stick with it in order to > make people coming from other language feel

Re: Art of Unit Testing

Christoph Zwerschke wrote: > I completely agree and I think it makes a lot of sense that unittest > calls setUp and tearDown for every single test. However, the fact that > this is *generally* the best way doesn't exclude the fact that there are > *exceptions* when it makes sense to setUp and te

Re: Art of Unit Testing

rafi wrote: > In order to unit test a function / method one should use mock objects, > otherwise you may not be sure that your code is faulty. 'should' may be too strong, 'may' may be better. In the meantime I found: http://python-mock.sourceforge.net/ my 2 cents -- rafi "Im

Re: Art of Unit Testing

Christoph Zwerschke wrote: > Björn Lindström wrote: > > I already gave the example of creating database connections > or even creating/importing whole databases. My question was, how do I > handle these cases with the standard lib unittest? I do not get why a unit test whould create/import a wh

Re: Art of Unit Testing

Christoph Zwerschke wrote: > Thanks for the link, Grig. I wasn't aware of the py lib so far. The > possibility to create fixtures at the three different scopes is exactly > what I was looking for. > > Anyway, I think it would be nice to have that feature in the standard > lib unittest as well. It

Re: Art of Unit Testing

Björn Lindström wrote: >>Would it make sense to add "globaleSetup" and "globalTearDown" methods >>to the TestCase class? > In general that's not such a good idea. I completely agree and I think it makes a lot of sense that unittest calls setUp and tearDown for every single test. However, the fact

Re: Art of Unit Testing

Thanks for the link, Grig. I wasn't aware of the py lib so far. The possibility to create fixtures at the three different scopes is exactly what I was looking for. Anyway, I think it would be nice to have that feature in the standard lib unittest as well. It should not be too hard to add setUpO

Re: Art of Unit Testing

""Björn Lindström"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Christoph Zwerschke <[EMAIL PROTECTED]> writes: > >> Would it make sense to add "globaleSetup" and "globalTearDown" methods >> to the TestCase class? I think at least it would not harm >> anybody. Where should such p

Re: Art of Unit Testing

Christoph Zwerschke <[EMAIL PROTECTED]> writes: > Would it make sense to add "globaleSetup" and "globalTearDown" methods > to the TestCase class? I think at least it would not harm > anybody. Where should such proposals be submitted? In general that's not such a good idea. If you build your tests

Re: Art of Unit Testing

The py.test module offers setup/teardown hooks at the method, class and module level. The scenario you're describing would be covered at the module level. See the py.test documentation for more details: