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
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
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 being overly
- 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: 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 --
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 make
- 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 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 the
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 tests/groups,
- 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 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 recursion
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 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):
- 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 of
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:
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
- 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 in
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
18 matches
Mail list logo
