Kevin,
On 11/13/2010 01:28 AM, Kevin Grittner wrote:
Should anyone else run into this, it's controlled by this in the test
scheduling definitions (the tdef values):
'xfail': True
There are other test flags you can override here, like 'skip' to skip
a test.
Correct. Looks like dtester
On 11/10/2010 10:58 PM, Peter Eisentraut wrote:
One thing to aim for, perhaps, would be to make all tools in use produce
a common output format, at least optionally, so that creating a common
test run dashboard or something like that is more easily possible. TAP
and xUnit come to mind.
Note
Markus Wanner wrote:
Note that dtester features a TAP reporter. However, the way Kevin
uses dtester, that probably won't give useful results. (As he uses
custom print statements to do more detailed reporting than TAP
could ever give you).
According to the TAP draft standard, any line not
On 11/12/2010 02:27 PM, Kevin Grittner wrote:
According to the TAP draft standard, any line not beginning with
'ok', 'not ok', or '#' is a comment and must be ignored by a TAP
consumer. They are considered comments, and the assumption is that
there can be many of them.
I stand corrected. Do
Markus Wanner wrote:
I stand corrected. Do you actually use the TapReporter?
No. I know so little about TAP that I wasn't aware that dtester
output was in the TAP format until I saw your post on this thread, so
I went searching for the format to see what I might do to become more
compliant
On 11/12/2010 02:43 PM, Kevin Grittner wrote:
Markus Wanner wrote:
I stand corrected. Do you actually use the TapReporter?
No. I know so little about TAP that I wasn't aware that dtester
output was in the TAP format
Well, there are three kinds of reporters: StreamReporter, TapReporter
Markus Wanner wrote:
Well, there are three kinds of reporters: StreamReporter,
TapReporter and CursesReporter. By default, either curser or stream
is chosen, depending on whether or not dtester thinks its stdout is
a terminal or not.
The CursesReporter moves up and down the lines to
On Nov 12, 2010, at 6:28 AM, Kevin Grittner wrote:
The CursesReporter moves up and down the lines to write results to
concurrently running tests. It's only useful on a terminal and
certainly gets confused by anything that moves the cursor (which a
plain 'print' certainly does).
Ah, well
David E. Wheeler wrote:
On Nov 12, 2010, at 6:28 AM, Kevin Grittner wrote:
I'll switch to TapReporter.
Oh, that would be great, because I can then have the TAP stuff I
plan to add just run your tests and harness the results along with
everything else.
I switched it with this patch:
On Nov 12, 2010, at 12:39 PM, Kevin Grittner wrote:
(2) If I wanted something to show in the TAP output, like the three
counts at the end of the test, what's the right way to do that? (I
suspect that printing with a '#' character at the front of the line
would do it, but that's probably not
I wrote:
(1) Any idea why it finds the success of the tests unexpected?
Should anyone else run into this, it's controlled by this in the test
scheduling definitions (the tdef values):
'xfail': True
There are other test flags you can override here, like 'skip' to skip
a test.
-Kevin
--
Robert Haas robertmh...@gmail.com writes:
I think the big hurdle with contrib isn't
that it's called contrib but that it's not part of the core server
and, in many cases, enabling a contrib module means editing
postgresql.conf and bouncing the server. Of course, there are
certainly SOME
Peter Eisentraut wrote:
On tis, 2010-11-09 at 14:00 -0800, David E. Wheeler wrote:
I've been talking to Nasby and Dunstan about adding a
Test::More/pgTAP-based test suite to the core. It wouldn't run
with the usual core suite used by developers, which would continue
to use pg_regress.
On Nov 10, 2010, at 5:31 AM, Kevin Grittner wrote:
For the Serializable Snapshot Isolation (SSI) patch I needed a test
suite which would handle concurrent sessions which interleaved
statements in predictable ways. I was told pgTAP wasn't a good
choice for that and went with Markus Wanner's
On Wed, Nov 10, 2010 at 08:33:13AM -0800, David Wheeler wrote:
On Nov 10, 2010, at 5:31 AM, Kevin Grittner wrote:
For the Serializable Snapshot Isolation (SSI) patch I needed a
test suite which would handle concurrent sessions which
interleaved statements in predictable ways. I was told
On 11/10/2010 08:31 AM, Kevin Grittner wrote:
I don't know if dtester meets the other needs people have, or whether
this is a complementary approach, but it seemed worth mentioning.
Where is this available? Is it self-contained? And what does it require?
cheers
andrew
--
Sent via
On Nov 10, 2010, at 9:48 AM, Andrew Dunstan wrote:
I don't know if dtester meets the other needs people have, or whether
this is a complementary approach, but it seemed worth mentioning.
Where is this available? Is it self-contained? And what does it require?
Python.
David E. Wheeler da...@kineticode.com wrote:
On Nov 10, 2010, at 9:48 AM, Andrew Dunstan wrote:
Where is this available? Is it self-contained? And what does it
require?
Python.
And some optional python packages, like twisted.
http://www.bluegap.ch/projects/dtester/
It looks like I
On Wed, Nov 10, 2010 at 15:31, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
For the Serializable Snapshot Isolation (SSI) patch I needed a test
suite which would handle concurrent sessions which interleaved
statements in predictable ways. I was told pgTAP wasn't a good
choice for that
Hi,
On 11/10/2010 07:28 PM, Kevin Grittner wrote:
It looks like I may have raised the issue at a particularly
inopportune time -- it looks like maybe Markus is reloading his git
repo based on the new official git repo for PostgreSQL.
Thanks for noticing me. The dtester repository should be
On ons, 2010-11-10 at 07:31 -0600, Kevin Grittner wrote:
I don't know if dtester meets the other needs people have, or whether
this is a complementary approach, but it seemed worth mentioning.
The right tool for the right job, I'd say.
One thing to aim for, perhaps, would be to make all tools
Marti Raudsepp ma...@juffo.org wrote:
Sounds like you could use pgTAP with dblink to do the same? :)
I had never read through the docs for dblink until you posted this.
In fact, it appears that some testing of proper SSI behavior can be
added to standard regression tests with dblink (without
On 11/10/2010 05:06 PM, Kevin Grittner wrote:
Marti Raudseppma...@juffo.org wrote:
Sounds like you could use pgTAP with dblink to do the same? :)
I had never read through the docs for dblink until you posted this.
In fact, it appears that some testing of proper SSI behavior can be
added
On Nov 10, 2010, at 2:15 PM, Andrew Dunstan wrote:
We already use some contrib stuff in the regression tests. (It really is time
we stopped calling it contrib.)
Call them core extensions. Works well considering Dimitri's work, which
explicitly makes them extensions. So maybe change the
David E. Wheeler da...@kineticode.com writes:
On Nov 10, 2010, at 2:15 PM, Andrew Dunstan wrote:
We already use some contrib stuff in the regression tests. (It really is
time we stopped calling it contrib.)
Call them core extensions. Works well considering Dimitri's work, which
explicitly
On Nov 10, 2010, at 3:17 PM, Tom Lane wrote:
We've been calling it contrib for a dozen years, so that name is
pretty well baked in by now. IMO renaming it is pointless and will
accomplish little beyond creating confusion and making back-patches
harder.
*Shrug*. Just change the name in the
On Wed, Nov 10, 2010 at 6:39 PM, David E. Wheeler da...@kineticode.com wrote:
On Nov 10, 2010, at 3:17 PM, Tom Lane wrote:
We've been calling it contrib for a dozen years, so that name is
pretty well baked in by now. IMO renaming it is pointless and will
accomplish little beyond creating
On Nov 9, 2010, at 12:18 PM, Peter Eisentraut wrote:
One possible way out is not to include these tests in the main test set
and instead require manual invocation.
Better ideas?
I've been talking to Nasby and Dunstan about adding a Test::More/pgTAP-based
test suite to the core. It wouldn't
2010/11/9 David E. Wheeler da...@kineticode.com:
On Nov 9, 2010, at 12:18 PM, Peter Eisentraut wrote:
One possible way out is not to include these tests in the main test set
and instead require manual invocation.
Better ideas?
I've been talking to Nasby and Dunstan about adding a
On Nov 9, 2010, at 2:42 PM, Cédric Villemain wrote:
Are you thinking of a contrib module 'pgtap' that we can use to
accomplish the optionnal regression tests ?
Oh, if the project wants it in contrib, sure. Otherwise I'd probably just have
the test stuff include it somehow.
David
--
Sent
2010/11/9 David E. Wheeler da...@kineticode.com:
On Nov 9, 2010, at 2:42 PM, Cédric Villemain wrote:
Are you thinking of a contrib module 'pgtap' that we can use to
accomplish the optionnal regression tests ?
Oh, if the project wants it in contrib, sure. Otherwise I'd probably just
have
On tis, 2010-11-09 at 14:00 -0800, David E. Wheeler wrote:
I've been talking to Nasby and Dunstan about adding a Test::More/pgTAP-based
test suite to the core. It wouldn't run with the usual core suite used by
developers, which would continue to use pg_regress. But they could run it if
they
32 matches
Mail list logo
