Thread: [PROPOSAL] TAP test example
Don't we need a simple example of TAP tests in src/test ? Something that test a trivial feature, but shows basic testing tricks? While explaining to my friends how does TAP test works I wrote an example TAP test. May be we we should add it to the core with sensible README explanation? -- Nikolay Shaplov Postgres Professional: http://www.postgrespro.com Russian Postgres Company
Attachment
On 11/19/15 8:42 AM, Nikolay Shaplov wrote:
> +sub psql_ok
> +{
> + my $db = shift;
> + my $sql = shift;
> + my $comment = shift;
Isn't the preferred method of parameter assignment to use @_?
Also, I'd think one of the examples should use DBI, since presumably one
of the big benefits to tap is not dealing with raw psql output...
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
В письме от 19 ноября 2015 09:39:41 пользователь Jim Nasby написал:
> On 11/19/15 8:42 AM, Nikolay Shaplov wrote:
> > +sub psql_ok
> > +{
> > + my $db = shift;
> > + my $sql = shift;
> > + my $comment = shift;
>
> Isn't the preferred method of parameter assignment to use @_?
Hm... it is the way I wrote perl programs. There is more then one way to do it
in perl, you know ;-) I think that this way is more understandable for others.
But this is not the issue. We can change it any way we like. The question do
we need such example at all, or no?
> Also, I'd think one of the examples should use DBI, since presumably one
> of the big benefits to tap is not dealing with raw psql output...
I wrote this example based on ssl TAP test. There was no DBI there. And I
think it was done for purpose. If we add DBI to tests, then we should add it
to build dependencies. And it is not a good idea, and so not a good example.
--
Nikolay Shaplov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
Nikolay Shaplov <n.shaplov@postgrespro.ru> writes:
> But this is not the issue. We can change it any way we like. The question do
> we need such example at all, or no?
I'm kind of -1 on the idea of a module that doesn't actually do something
*useful*. Let's write some actual tests instead, and make them readable
enough that people can steal and repurpose the skeleton easily.
> I wrote this example based on ssl TAP test. There was no DBI there. And I
> think it was done for purpose. If we add DBI to tests, then we should add it
> to build dependencies. And it is not a good idea, and so not a good example.
Agreed. We aren't going to accept any core tests that depend on DBI/DBD.
Now, that might be a fine example for tests written to test something that
uses Postgres ... but not as an example of how to write a core test.
regards, tom lane
On 11/19/15 9:57 AM, Tom Lane wrote: >> >I wrote this example based on ssl TAP test. There was no DBI there. And I >> >think it was done for purpose. If we add DBI to tests, then we should add it >> >to build dependencies. And it is not a good idea, and so not a good example. > Agreed. We aren't going to accept any core tests that depend on DBI/DBD. > Now, that might be a fine example for tests written to test something that > uses Postgres ... but not as an example of how to write a core test. Isn't one of the goals of the TAP framework to be able to write SQL level tests where we don't have to worry about random output changes, like what line number on a script caused an error? -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
Jim Nasby <Jim.Nasby@bluetreble.com> writes:
> On 11/19/15 9:57 AM, Tom Lane wrote:
>> Agreed. We aren't going to accept any core tests that depend on DBI/DBD.
>> Now, that might be a fine example for tests written to test something that
>> uses Postgres ... but not as an example of how to write a core test.
> Isn't one of the goals of the TAP framework to be able to write SQL
> level tests where we don't have to worry about random output changes,
> like what line number on a script caused an error?
So?
Actually, I would say that one of the most serious black marks against
every one of the TAP tests we've got is the difficulty of finding out why
a test failed, when that happens. "ok" versus "not ok" simply doesn't cut
it. So the idea of not reporting what the actual output was doesn't seem
attractive to me at all.
regards, tom lane
В письме от 19 ноября 2015 10:57:27 пользователь Tom Lane написал: > Nikolay Shaplov <n.shaplov@postgrespro.ru> writes: > > But this is not the issue. We can change it any way we like. The question > > do we need such example at all, or no? > > I'm kind of -1 on the idea of a module that doesn't actually do something > *useful*. Actually it tests that sameuser option from pg_hba.conf works as expected. Allow user to connect only to database with the same name as user name. I can't say it is something really useful. But my intention was to write an example, so I choose the most simple functionality to test, so the user of the example can pay all attention to perl related staff. I just thought this example might be useful to others. If so, I can prepare it for commit. Otherwise I will just use it were I intended. -- Nikolay Shaplov Postgres Professional: http://www.postgrespro.com Russian Postgres Company