[PROPOSAL] TAP test example

Started by Nikolay Shaplovabout 10 years ago7 messages

n.shaplov@postgrespro.ru

about 10 years ago

1 attachment(s)

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

Attachments:

tap_example_proposal.difftext/x-patch; charset=UTF-8; name=tap_example_proposal.diffDownload

diff --git a/src/test/Makefile b/src/test/Makefile
index b713c2c..a45129c 100644
--- a/src/test/Makefile
+++ b/src/test/Makefile
@@ -17,7 +17,7 @@ SUBDIRS = regress isolation modules
 # We don't build or execute examples/, locale/, or thread/ by default,
 # but we do want "make clean" etc to recurse into them.  Likewise for ssl/,
 # because the SSL test suite is not secure to run on a multi-user system.
-ALWAYS_SUBDIRS = examples locale thread ssl
+ALWAYS_SUBDIRS = examples locale thread ssl tap-examples
 
 # We want to recurse to all subdirs for all standard targets, except that
 # installcheck and install should not recurse into the subdirectory "modules".
diff --git a/src/test/tap-examples/Makefile b/src/test/tap-examples/Makefile
new file mode 100644
index 0000000..e0d6e10
--- /dev/null
+++ b/src/test/tap-examples/Makefile
@@ -0,0 +1,7 @@
+
+subdir = src/test/tap-examples
+top_builddir = ../../..
+include $(top_builddir)/src/Makefile.global
+
+check:
+	$(prove_check)
diff --git a/src/test/tap-examples/TapExamples.pm b/src/test/tap-examples/TapExamples.pm
new file mode 100644
index 0000000..80fe13b
--- /dev/null
+++ b/src/test/tap-examples/TapExamples.pm
@@ -0,0 +1,34 @@
+package TapExamples;
+
+use strict;
+use TestLib;
+use Test::More;
+
+use Exporter 'import';
+our @EXPORT = qw(
+  psql_ok psql_fails
+);
+
+sub psql_ok
+{
+	my $db = shift;
+	my $sql = shift;
+	my $comment = shift;
+	my $res;
+	eval {$res = psql($db,$sql)};
+	$res = 0 if $@;
+	ok($res, $comment);
+}
+
+sub psql_fails
+{
+	my $db = shift;
+	my $sql = shift;
+	my $comment = shift;
+	my $res;
+	eval {$res = psql($db,$sql)};
+	$res = 0 if $@;
+	ok(!$res, $comment);
+}
+
+1;
diff --git a/src/test/tap-examples/t/001_sameuser_test.pl b/src/test/tap-examples/t/001_sameuser_test.pl
new file mode 100644
index 0000000..b7236ae
--- /dev/null
+++ b/src/test/tap-examples/t/001_sameuser_test.pl
@@ -0,0 +1,36 @@
+# Minimal test testing streaming replication
+use strict;
+use warnings;
+use TestLib;
+use Test::More "no_plan";
+use TapExamples;
+
+my $tempdir = TestLib::tempdir;
+#my $tempdir = 'my_tmp';
+
+diag "setting up data directory in \"$tempdir\"...";
+
+my $current_user = (getpwuid($>))[0];
+my $db1 = $current_user;
+my $db2 = "${current_user}_another_db";
+
+diag "Running postgres as user '$current_user' with default configuration";
+start_test_server($tempdir);
+
+psql_ok('postgres', "CREATE DATABASE $db1", "Creating DB '$db1'");
+psql_ok('postgres', "CREATE DATABASE $db2", "Creating DB '$db2'");
+
+psql_ok($db1, "select now()", "Connecting to '$db1'");
+psql_ok($db2, "select now()", "Connecting to '$db2'");
+
+diag "Updateing pg_hba.conf, setting 'local sameuser all trust'";
+open HBA, ">$tempdir/pgdata/pg_hba.conf";
+print HBA "# TYPE  DATABASE        USER            ADDRESS                 METHOD\n";
+print HBA "local   sameuser        all                                     trust \n";
+close HBA;
+
+diag "Restarting postgres";
+restart_test_server();
+
+psql_ok($db1, "select now()", "Connecting to '$db1'");
+psql_fails($db2, "select now()", "Should fail when connecting to '$db2'");

Jim Nasby

Jim.Nasby@BlueTreble.com

about 10 years ago

In reply to: Nikolay Shaplov (#1)

Re: [PROPOSAL] TAP test example

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Nikolay Shaplov

n.shaplov@postgrespro.ru

about 10 years ago

In reply to: Jim Nasby (#2)

Re: [PROPOSAL] TAP test example

В письме от 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane

tgl@sss.pgh.pa.us

about 10 years ago

In reply to: Nikolay Shaplov (#3)

Re: [PROPOSAL] TAP test example

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Jim Nasby

Jim.Nasby@BlueTreble.com

about 10 years ago

In reply to: Tom Lane (#4)

Re: [PROPOSAL] TAP test example

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane

tgl@sss.pgh.pa.us

about 10 years ago

In reply to: Jim Nasby (#5)

Re: [PROPOSAL] TAP test example

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Nikolay Shaplov

n.shaplov@postgrespro.ru

about 10 years ago

In reply to: Tom Lane (#4)

Re: [PROPOSAL] TAP test example

В письме от 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers