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 alternative rather than
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,
def
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
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
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?
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 frameworks for
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
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 that
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 proposals be
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 of sense that
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
discouraged to
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 pythonic)
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 why
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
Using mock
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 the
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.
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 something
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 much time,
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 been done
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 requirement for extreme
- 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 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 pythonic)
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,
because
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 releasing
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 reasons why there are
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
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 add
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 out
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's the
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:
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 proposals be
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
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 that
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
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 whole
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
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
37 matches
Mail list logo
