On Tue, 2010-02-16 at 02:09 -0500, Glyph Lefkowitz wrote:
>
> > > In a recent message he was talking about either breaking
> > > compatibility with TestSuite implementations that override run(),
> > > or test-reordering - both of which I consider important, core
> > > features of the unittest m
On Feb 15, 2010, at 3:50 PM, Michael Foord wrote:
> On 15/02/2010 20:27, Glyph Lefkowitz wrote:
>>
>>
>> On Feb 13, 2010, at 12:46 PM, Guido van Rossum wrote:
>>
>>> On Fri, Feb 12, 2010 at 8:01 PM, Glyph Lefkowitz
>>> wrote:
I find setUpClass more hostile to *other* kinds of testing, be
On 15/02/2010 20:27, Glyph Lefkowitz wrote:
On Feb 13, 2010, at 12:46 PM, Guido van Rossum wrote:
On Fri, Feb 12, 2010 at 8:01 PM, Glyph Lefkowitz
mailto:gl...@twistedmatrix.com>> wrote:
On Feb 11, 2010, at 1:11 PM, Guido van Rossum wrote:
For what it's worth, I am a big fan of abusing test
On Feb 13, 2010, at 12:46 PM, Guido van Rossum wrote:
> On Fri, Feb 12, 2010 at 8:01 PM, Glyph Lefkowitz
> wrote:
>> On Feb 11, 2010, at 1:11 PM, Guido van Rossum wrote:
>>
>> For what it's worth, I am a big fan of abusing test frameworks in generally,
>> and pyunit specifically, to perform ev
On 15/02/2010 17:05, Michael Foord wrote:
[snip]
This is also an interesting point. The 'naive' implementation, which I
think I prefer, only runs the setUpModule of modules actually
containing tests. Similarly setUpClass is only called on classes with
actual tests, although they may call up to
On 13/02/2010 04:01, Glyph Lefkowitz wrote:
[snipping some good points...]
Regarding the objection that setUp/tearDown for classes would run into
issues with subclassing, I propose to let the standard semantics of
subclasses do their job. Thus a subclass that overrides setUpClass or
tearDownClass
On 13/02/2010 11:00, Robert Collins wrote:
On Sat, 2010-02-13 at 10:42 +, Antoine Pitrou wrote:
Robert Collins robertcollins.net> writes:
I'm not personally very keen on inspecting everything in self.__dict__,
I suspect it would tickle bugs in other unittest extensions. However
On Fri, Feb 12, 2010 at 8:01 PM, Glyph Lefkowitz
wrote:
> On Feb 11, 2010, at 1:11 PM, Guido van Rossum wrote:
>
>> I have skimmed this thread (hence this reply to the first rather than
>> the last message), but in general I am baffled by the hostility of
>> testing framework developers towards th
On Sat, 2010-02-13 at 10:42 +, Antoine Pitrou wrote:
> Robert Collins robertcollins.net> writes:
> >
> > I'm not personally very keen on inspecting everything in self.__dict__,
> > I suspect it would tickle bugs in other unittest extensions. However I'm
> > not really /against/ it - I don't t
Robert Collins robertcollins.net> writes:
>
> I'm not personally very keen on inspecting everything in self.__dict__,
> I suspect it would tickle bugs in other unittest extensions. However I'm
> not really /against/ it - I don't think it will result in bad test
> behaviour or isolation issues. So
R. David Murray wrote:
On Thu, 11 Feb 2010 12:41:37 +, Michael Foord
wrote:
On 11/02/2010 12:30, Nick Coghlan wrote:
The test framework might promise to do the following for each test:
with get_module_cm(test_instance): # However identified
with get_class_cm(test_instance): # How
On Fri, 2010-02-12 at 12:27 -0800, Guido van Rossum wrote:
> On Fri, Feb 12, 2010 at 12:20 PM, wrote:
> > The idea is that you're declaring what the tests need in order to work.
> > You're not explicitly defining the order in which things are set up and torn
> > down. That is left up to another
On Sat, 2010-02-13 at 01:04 +, Michael Foord wrote:
> > However from this example I *cannot* guess whether those resources are
> > set up and torn down per test or per test class.
> This particular example is the equivalent of setUpClass - so by
> declaring the resource as a class attribute
On Feb 11, 2010, at 1:11 PM, Guido van Rossum wrote:
> I have skimmed this thread (hence this reply to the first rather than
> the last message), but in general I am baffled by the hostility of
> testing framework developers towards their users. The arguments
> against class- and module-level seUp
On 12/02/2010 19:48, Guido van Rossum wrote:
[snip...]
Here's a current minimal example of using Test Resources. It could be
simplified further with helper functions and by some of the functionality
moving into unittest itself. OptimisingTestSuite here ensures that the
resource is created before
On 08:27 pm, gu...@python.org wrote:
On Fri, Feb 12, 2010 at 12:20 PM, wrote:
The idea is that you're declaring what the tests need in order to
work.
You're not explicitly defining the order in which things are set up
and torn
down. �That is left up to another part of the library to determin
Michael Foord writes:
> The advantage of setUpClass and setUpModule is that they allow you to
> have shared fixtures shared between tests, essential for certain kinds
> of testing. […]
Yes, this would be very useful for non-unit tests.
> My *hope* is that we provide a general solution, possibly
On Fri, Feb 12, 2010 at 12:20 PM, wrote:
> The idea is that you're declaring what the tests need in order to work.
> You're not explicitly defining the order in which things are set up and torn
> down. That is left up to another part of the library to determine.
>
> One such other part, Optimisi
On 07:48 pm, gu...@python.org wrote:
On Fri, Feb 12, 2010 at 7:49 AM, Michael Foord
wrote:
My *hope* is that we provide a general solution, possibly based on all
or
part of Test Resources, with an easy mechanism for the setUpClass and
setUpModule but also solves the more general case of sharin
On Fri, Feb 12, 2010 at 7:49 AM, Michael Foord
wrote:
> My *hope* is that we provide a general solution, possibly based on all or
> part of Test Resources, with an easy mechanism for the setUpClass and
> setUpModule but also solves the more general case of sharing fixtures
> between tests. If that
On 11/02/2010 18:11, Guido van Rossum wrote:
On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord wrote:
The next 'big' change to unittest will (may?) be the introduction of class
and module level setUp and tearDown. This was discussed on Python-ideas and
Guido supported them. They can be useful b
On Tue, Feb 9, 2010 at 2:04 PM, Michael Foord wrote:
> On 09/02/2010 19:00, Olemis Lang wrote:
>>
>> Sorry. I had not finished the previous message
>>
>> On Tue, Feb 9, 2010 at 1:55 PM, Olemis Lang wrote:
>>> On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang wrote:
On Tue, Feb 9, 2010 at 11:42 AM
Holger Krekel wrote:
> In my experience, integration and
> functional testing is a complex and evolving topic, usually requiring
> more from the tool or framework than classic unit-testing.
Assignment for the reader: compare and contrast unittest and
test.regrtest (including test.support and frie
R. David Murray wrote:
> would be easier to write, be more maintainable, and be easier to
> understand when reading the code than the equivalent setUp and tearDown
> methods would be.
>
> I'm not saying it would be easy to implement, and as you say backward
> compatibility is a key concern.
That'
On 2010-02-11 17:57 PM, Holger Krekel wrote:
On Fri, Feb 12, 2010 at 12:00 AM, Robert Kern wrote:
On 2010-02-11 16:20 PM, Ben Finney wrote:
Guido van Rossumwrites:
The argument that a unittest framework shouldn't be "abused" for
regression tests (or integration tests, or whatever) is a
On Fri, Feb 12, 2010 at 12:00 AM, Robert Kern wrote:
> On 2010-02-11 16:20 PM, Ben Finney wrote:
>>
>> Guido van Rossum writes:
>
>>> The argument that a unittest framework shouldn't be "abused" for
>>> regression tests (or integration tests, or whatever) is also bizarre
>>> to my mind. Surely if
On 2010-02-11 16:20 PM, Ben Finney wrote:
Guido van Rossum writes:
The argument that a unittest framework shouldn't be "abused" for
regression tests (or integration tests, or whatever) is also bizarre
to my mind. Surely if a testing framework applies to multiple kinds of
testing that's a good
Guido van Rossum writes:
> The potential for abuse in and of itself should not be an argument
> against a feature; it must always be weighed against the advantages.
It's both, surely? The potential for abuse of something is an argument
against it; *and* that argument should be weighed against ot
On Thu, Feb 11, 2010 at 11:26 AM, Holger Krekel wrote:
> Hi Guido,
>
> On Thu, Feb 11, 2010 at 7:11 PM, Guido van Rossum wrote:
>> On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord
>> wrote:
>>> The next 'big' change to unittest will (may?) be the introduction of class
>>> and module level setUp an
On Thu, 11 Feb 2010 16:08:54 +, Michael Foord
wrote:
> On 11/02/2010 15:56, R. David Murray wrote:
> > On Thu, 11 Feb 2010 12:41:37 +, Michael
> > Foord wrote:
> >> On 11/02/2010 12:30, Nick Coghlan wrote:
> >>> The test framework might promise to do the following for each test:
> >>>
>
Hi Guido,
On Thu, Feb 11, 2010 at 7:11 PM, Guido van Rossum wrote:
> On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord
> wrote:
>> The next 'big' change to unittest will (may?) be the introduction of class
>> and module level setUp and tearDown. This was discussed on Python-ideas and
>> Guido suppo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Olemis Lang wrote:
> On Thu, Feb 11, 2010 at 1:11 PM, Guido van Rossum wrote:
>> Regarding the objection that setUp/tearDown for classes would run into
>> issues with subclassing, I propose to let the standard semantics of
>> subclasses do their job.
Le Thu, 11 Feb 2010 10:56:32 -0500, R. David Murray a écrit :
>
> @unittest.case_context(foo_cm)
> @unittest.test_context(foo_test_cm)
> class TestFoo(unittest.TestCase):
>
> def test_bar:
> foo = Foo(self.baz, testing=True)
> self.assertTrue("Context managers are cool")
>
>
On Thu, Feb 11, 2010 at 1:11 PM, Guido van Rossum wrote:
> On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord
> wrote:
>> The next 'big' change to unittest will (may?) be the introduction of class
>> and module level setUp and tearDown. This was discussed on Python-ideas and
>> Guido supported them.
On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord wrote:
> The next 'big' change to unittest will (may?) be the introduction of class
> and module level setUp and tearDown. This was discussed on Python-ideas and
> Guido supported them. They can be useful but are also very easy to abuse
> (too much sha
On Thu, Feb 11, 2010 at 11:18 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Olemis Lang wrote:
>> On Tue, Feb 9, 2010 at 8:10 PM, Ben Finney
>> wrote:
>>> Michael Foord writes:
>>>
I've used unittest for long running functional and integration tests
(in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
exar...@twistedmatrix.com wrote:
> On 04:18 pm, tsea...@palladion.com wrote:
>> Just as a point of reference: zope.testing[1] has a "layer" feature
>> which is used to support this usecase: a layer is a class namedd as an
>> attribute of a testcase,
On 04:18 pm, tsea...@palladion.com wrote:
Just as a point of reference: zope.testing[1] has a "layer" feature
which is used to support this usecase: a layer is a class namedd as an
attribute of a testcase, e.g.:
class FunctionalLayer:
@classmethod
def setUp(klass):
""" Do som
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Olemis Lang wrote:
> On Tue, Feb 9, 2010 at 8:10 PM, Ben Finney wrote:
>> Michael Foord writes:
>>
>>> I've used unittest for long running functional and integration tests
>>> (in both desktop and web applications). The infrastructure it provides
>>>
On 11/02/2010 15:56, R. David Murray wrote:
On Thu, 11 Feb 2010 12:41:37 +, Michael Foord
wrote:
On 11/02/2010 12:30, Nick Coghlan wrote:
The test framework might promise to do the following for each test:
with get_module_cm(test_instance): # However identified
with g
On Thu, 11 Feb 2010 12:41:37 +, Michael Foord
wrote:
> On 11/02/2010 12:30, Nick Coghlan wrote:
> > The test framework might promise to do the following for each test:
> >
> >with get_module_cm(test_instance): # However identified
> > with get_class_cm(test_instance): # However ident
On 10 Feb, 02:47 pm, ole...@gmail.com wrote:
On Tue, Feb 9, 2010 at 6:15 PM, wrote:
For what it's worth, we just finished *removing* support for
setUpClass and
tearDownClass from Trial.
Ok ... but why ? Are they considered dangerous for modern societies ?
Several reasons:
- Over the m
On Thu, Feb 11, 2010 at 10:10 AM, wrote:
> On 02:41 pm, ole...@gmail.com wrote:
>>
>> On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
>> wrote:
>>>
>>> On 11/02/2010 12:30, Nick Coghlan wrote:
Michael Foord wrote:
>
> I'm not sure what response I expect from this email, and neit
On Thu, Feb 11, 2010 at 10:11 AM, Olemis Lang wrote:
> On Thu, Feb 11, 2010 at 9:41 AM, Olemis Lang wrote:
>> On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
>> wrote:
>>> On 11/02/2010 12:30, Nick Coghlan wrote:
Michael Foord wrote:
>
> I'm not sure what response I expect
On Thu, Feb 11, 2010 at 9:41 AM, Olemis Lang wrote:
> On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
> wrote:
>> On 11/02/2010 12:30, Nick Coghlan wrote:
>>>
>>> Michael Foord wrote:
>>>
I'm not sure what response I expect from this email, and neither option
will be implemented wit
On 02:41 pm, ole...@gmail.com wrote:
On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
wrote:
On 11/02/2010 12:30, Nick Coghlan wrote:
Michael Foord wrote:
I'm not sure what response I expect from this email, and neither
option
will be implemented without further discussion - possibly at the
On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
wrote:
> On 11/02/2010 12:30, Nick Coghlan wrote:
>>
>> Michael Foord wrote:
>>
>>>
>>> I'm not sure what response I expect from this email, and neither option
>>> will be implemented without further discussion - possibly at the PyCon
>>> sprints - bu
On 11/02/2010 12:30, Nick Coghlan wrote:
Michael Foord wrote:
I'm not sure what response I expect from this email, and neither option
will be implemented without further discussion - possibly at the PyCon
sprints - but I thought I would make it clear what the possible
directions are.
Michael Foord wrote:
> I'm not sure what response I expect from this email, and neither option
> will be implemented without further discussion - possibly at the PyCon
> sprints - but I thought I would make it clear what the possible
> directions are.
I'll repeat what I said in the python-ideas th
On Wed, Feb 10, 2010 at 3:56 PM, R. David Murray wrote:
> On Wed, 10 Feb 2010 09:45:41 -0500, Olemis Lang wrote:
>> On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel
>> wrote:
>> > On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney
>> > wrote:
>> >> Michael Foord writes:
>> >>
>> >>> The next 'big' cha
On Wed, 10 Feb 2010 09:45:41 -0500, Olemis Lang wrote:
> On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel wrote:
> > On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney
> > wrote:
> >> Michael Foord writes:
> >>
> >>> The next 'big' change to unittest will (may?) be the introduction of
> >>> class and mo
On Tue, Feb 9, 2010 at 8:10 PM, Ben Finney wrote:
> Michael Foord writes:
>
>> I've used unittest for long running functional and integration tests
>> (in both desktop and web applications). The infrastructure it provides
>> is great for this. Don't get hung up on the fact that it is called
>> un
On Tue, Feb 9, 2010 at 6:15 PM, wrote:
> On 10:42 pm, fuzzy...@voidspace.org.uk wrote:
>>
>> On 09/02/2010 21:57, Ben Finney wrote:
>>>
>>> Michael Foord writes:
The next 'big' change to unittest will (may?) be the introduction of
class and module level setUp and tearDown. This wa
On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel wrote:
> On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney
> wrote:
>> Michael Foord writes:
>>
>>> The next 'big' change to unittest will (may?) be the introduction of
>>> class and module level setUp and tearDown. This was discussed on
>>> Python-ideas
Michael Foord writes:
> I've used unittest for long running functional and integration tests
> (in both desktop and web applications). The infrastructure it provides
> is great for this. Don't get hung up on the fact that it is called
> unittest. In fact for many users the biggest reason it isn't
On 10:42 pm, fuzzy...@voidspace.org.uk wrote:
On 09/02/2010 21:57, Ben Finney wrote:
Michael Foord writes:
The next 'big' change to unittest will (may?) be the introduction of
class and module level setUp and tearDown. This was discussed on
Python-ideas and Guido supported them. They can be us
On 09/02/2010 21:57, Ben Finney wrote:
Michael Foord writes:
The next 'big' change to unittest will (may?) be the introduction of
class and module level setUp and tearDown. This was discussed on
Python-ideas and Guido supported them. They can be useful but are also
very easy to abuse (too
On 2010-02-09 15:57 PM, Ben Finney wrote:
Is there a better third-party framework for use in these cases? As
Olemis points out later in this thread, I don't think it's good for the
‘unittest’ module to keep growing for uses that aren't focussed on unit
tests (as contrasted with other kinds of te
On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney wrote:
> Michael Foord writes:
>
>> The next 'big' change to unittest will (may?) be the introduction of
>> class and module level setUp and tearDown. This was discussed on
>> Python-ideas and Guido supported them. They can be useful but are also
>> ver
On Tue, Feb 9, 2010 at 4:57 PM, Ben Finney wrote:
> Michael Foord writes:
>
>> The next 'big' change to unittest will (may?) be the introduction of
>> class and module level setUp and tearDown. This was discussed on
>> Python-ideas and Guido supported them. They can be useful but are also
>> very
Michael Foord writes:
> The next 'big' change to unittest will (may?) be the introduction of
> class and module level setUp and tearDown. This was discussed on
> Python-ideas and Guido supported them. They can be useful but are also
> very easy to abuse (too much shared state, monolithic test cla
On Tue, Feb 9, 2010 at 2:16 PM, Brian Curtin wrote:
> On Tue, Feb 9, 2010 at 12:29, Olemis Lang wrote:
>>
>> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
>> wrote:
>> > I'm pretty sure I can introduce setUpClass and setUpModule without
>> > breaking
>> > compatibility with existing unittest ex
On Tue, Feb 9, 2010 at 1:44 PM, Michael Foord wrote:
> On 09/02/2010 17:57, Antoine Pitrou wrote:
>>
>> Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit :
>>
>>>
>>> The next 'big' change to unittest will (may?) be the introduction of
>>> class and module level setUp and tearDown. This wa
On 09/02/2010 19:14, Holger Krekel wrote:
[snip...]
and
all tests in the class / module will have an explicit skip in the event of a
setUp failure.
I think reporting tests as skipped when the setup failed is a bad idea.
Out of several years of practise with skips and large test suites
On Tue, Feb 9, 2010 at 12:29, Olemis Lang wrote:
> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
> wrote:
> > I'm pretty sure I can introduce setUpClass and setUpModule without
> breaking
> > compatibility with existing unittest extensions or backwards
> compatibility
> > issues
>
> Is it possi
On Tue, Feb 9, 2010 at 7:29 PM, Olemis Lang wrote:
> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
> wrote:
>> Hello all,
>>
>> Several
>> authors of other Python testing frameworks spoke up *against* them, but
>> several *users* of test frameworks spoke up in favour of them. ;-)
>>
>
> +1 for h
On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou wrote:
> Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit :
>>
>> The next 'big' change to unittest will (may?) be the introduction of
>> class and module level setUp and tearDown. This was discussed on
>> Python-ideas and Guido supported th
On 09/02/2010 19:00, Olemis Lang wrote:
Sorry. I had not finished the previous message
On Tue, Feb 9, 2010 at 1:55 PM, Olemis Lang wrote:
On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang wrote:
On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
wrote:
Hello all,
Several
authors
Sorry. I had not finished the previous message
On Tue, Feb 9, 2010 at 1:55 PM, Olemis Lang wrote:
> On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang wrote:
>> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
>> wrote:
>>> Hello all,
>>>
>>> Several
>>> authors of other Python testing frameworks spoke
On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang wrote:
> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
> wrote:
>> Hello all,
>>
>> Several
>> authors of other Python testing frameworks spoke up *against* them, but
>> several *users* of test frameworks spoke up in favour of them. ;-)
>>
>
> +1 for h
On 09/02/2010 17:57, Antoine Pitrou wrote:
Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit :
The next 'big' change to unittest will (may?) be the introduction of
class and module level setUp and tearDown. This was discussed on
Python-ideas and Guido supported them. They can be usef
On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
wrote:
> Hello all,
>
> Several
> authors of other Python testing frameworks spoke up *against* them, but
> several *users* of test frameworks spoke up in favour of them. ;-)
>
+1 for having something like that included in unittest
> I'm pretty sure
Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit :
>
> The next 'big' change to unittest will (may?) be the introduction of
> class and module level setUp and tearDown. This was discussed on
> Python-ideas and Guido supported them. They can be useful but are also
> very easy to abuse (too
Hello all,
The next 'big' change to unittest will (may?) be the introduction of
class and module level setUp and tearDown. This was discussed on
Python-ideas and Guido supported them. They can be useful but are also
very easy to abuse (too much shared state, monolithic test classes and
module
74 matches
Mail list logo
