Test::Builder has a method use_numbers to turn off test numbering; this
can be useful when running tests in different processes. But the doc
says:
> Most useful when you can't depend on the test output order, such as when
threads or forking is involved.
>
> Test::Harness will accept either, but a
- Original Message
From: Collin Winter <[EMAIL PROTECTED]>
> On the other hand, one thing I do recall clearly is that when I
> started doing a lot of testing in Python, I thought it was stupid that
> things like ``self.assertEquals(foo(), bar())`` didn't count as
> "tests" like they did i
On 8/15/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
On 15/08/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> The TestCase *classes* are groups of tests, but each TestCase
> *instance* is only a single test, meaning that
> ``str(TestCase('somemethod_name'))`` would invoke TestCase.__str__().
In the
On 15/08/06, Collin Winter <[EMAIL PROTECTED]> wrote:
On 8/15/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
> On 15/08/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > The solution to this particular issue would be to have your SomeTest
> > class override TestCase.id(), TestCase.__str__() and/or
> >
On 8/15/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
On 15/08/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> The solution to this particular issue would be to have your SomeTest
> class override TestCase.id(), TestCase.__str__() and/or
> TestCase.__repr__() to take into account the data attribute.
On 15/08/06, Collin Winter <[EMAIL PROTECTED]> wrote:
On 8/15/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
> Where this becomes more important is when you start constructing
> suites automatically. For example
>
> class SomeTest(unittest.TestCase):
> def __init__(self, data):
> self.data = da
- Original Message
From: Fergal Daly <[EMAIL PROTECTED]>
> I don't want to get involved in another lengthy argument but this is
> not recursion.
Sorry if I was unclear. I was only using recursion as an example of something
one might see but, if one hadn't used it, not seeing the merit
On 8/15/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
Where this becomes more important is when you start constructing
suites automatically. For example
class SomeTest(unittest.TestCase):
def __init__(self, data):
self.data = data
unittest.TestCase.__init__(self)
def test_foo(self):
On 15/08/06, Collin Winter <[EMAIL PROTECTED]> wrote:
On 8/15/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
> I'm actualy talking about TestSuite objects. Here's some Python
>
[snip example]
>
> So the structure is like this:
>
> all_suites
> suite1
> ATest
> testFooBar
> testOther
On 15/08/06, Ovid <[EMAIL PROTECTED]> wrote:
- Original Message
From: Collin Winter <[EMAIL PROTECTED]>
> FWIW, I've never come across a situation using unittest where knowing
> the structure would be important (though I can imagine such cases).
I remember when I first encountered recu
- Original Message
From: Collin Winter <[EMAIL PROTECTED]>
> FWIW, I've never come across a situation using unittest where knowing
> the structure would be important (though I can imagine such cases).
I remember when I first encountered recursion back in the early 80s. Almost all
of my
On 8/15/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
I'm actualy talking about TestSuite objects. Here's some Python
[snip example]
So the structure is like this:
all_suites
suite1
ATest
testFooBar
testOther
AnotherTest
testBuz
suite2
...
SomeOtherTest
.
On 15/08/06, Collin Winter <[EMAIL PROTECTED]> wrote:
On 8/15/06, Ovid <[EMAIL PROTECTED]> wrote:
> - Original Message
> From: Fergal Daly <[EMAIL PROTECTED]>
>
> > XUnit allows heirarchical grouping, TAP does not. DUnit (Delphi's
> > XUnit) comes with a GUI that shows you a tree of test
On 8/15/06, Ovid <[EMAIL PROTECTED]> wrote:
- Original Message
From: Fergal Daly <[EMAIL PROTECTED]>
> XUnit allows heirarchical grouping, TAP does not. DUnit (Delphi's
> XUnit) comes with a GUI that shows you a tree of tests/groups,
This is the sort of input that other's outside of th
- Original Message
From: Fergal Daly <[EMAIL PROTECTED]>
> XUnit allows heirarchical grouping, TAP does not. DUnit (Delphi's
> XUnit) comes with a GUI that shows you a tree of tests/groups,
This is the sort of input that other's outside of the Perl community might be
able to give due to
On 15/08/06, Adrian Howard <[EMAIL PROTECTED]> wrote:
On 14 Aug 2006, at 21:53, Ovid wrote:
[snip]
> My personal thought is that either Andy Lester or Schwern start
> such a mailing list. Then we need to contact the major players
> from other languages and get them to join and see how we can mak
On Aug 15, 2006, at 11:29 AM, Michael Peters wrote:
I think this is the most important benefit. Test runs aren't bound
to the single
time it was run with a certain harness. They can be captured and
viewed later by
the same developer or shared among developers. If the report is
descriptive
e
- Original Message
From: Ovid <[EMAIL PROTECTED]>
> Is there something wrong with my TAPx::Parser?
And as a side note, if anyone likes it and thinks it can be *the* TAP::Harness
and has the power to bless that change, I'll happily turn it over.
Cheers,
Ovid
-- Buy the book -- http://
- Original Message
From: Michael G Schwern <[EMAIL PROTECTED]>
> Trouble is at the moment all this is still in the prototype stage.
> And none of them are killer.
Is there something wrong with my TAPx::Parser? So far, I think it's the
closest implementation we have to the TAP::Harness
- Original Message
From: Michael Peters <[EMAIL PROTECTED]>
> Imagine getting a bug report of your
> test suite failing along with the full TAP output of the test run.
That needs to be handled carefully. Currently there's no problem with TAP
parsing an infinite stream (Test::AtRuntime)
Michael G Schwern wrote:
> On 8/15/06, Adrian Howard <[EMAIL PROTECTED]> wrote:
>> To be honest, I'm not entirely sure that I could come up with a
>> really convincing argument for TAP for an audience using JUnit,
>> TestNG and similar...
>>
>> Do we have a convincing argument? Maybe I'm just bei
On 8/15/06, Adrian Howard <[EMAIL PROTECTED]> wrote:
To be honest, I'm not entirely sure that I could come up with a
really convincing argument for TAP for an audience using JUnit,
TestNG and similar...
Do we have a convincing argument? Maybe I'm just being overly
pessimistic today :-)
The sep
On 8/14/06, Ovid <[EMAIL PROTECTED]> wrote:
If anyone likes this idea, I've been accepted to attend Google's Automated
Testing Conference in London
I shall also be there and shall also speak to people about TAP. I
think about 3 other London.pm-ers will also be there. Thing is, I only
use TAP
as i work on parrot, i happen to know a few language designers. i know
they're interested in providing feedback on the proposed TAP changes, but
(perhaps because i'm new to the list) i don't see a good thread to point
them to. is there a summary of changes, or something i've missed that would
be a
On Mon, Aug 14, 2006 at 07:12:06PM -0700, chromatic wrote:
> PS - sbk30, please don't send me any more automated followup messages. Fix
> your mailing software.
I've found that our resident neighbourhood BOFHs have been very helpful at
forcibly un-subscribing anyone anti-social enough to be se
On 14 Aug 2006, at 21:53, Ovid wrote:
[snip]
My personal thought is that either Andy Lester or Schwern start
such a mailing list. Then we need to contact the major players
from other languages and get them to join and see how we can make
TAP a more widely accepted protocol. We know the ben
26 matches
Mail list logo
