Increasing code-coverage of 'make check'
Hi,
I was checking code-coverage of 'make check' and saw that the regression
tests don't touch files like psql_help.c at all (read 0%).
Attached is a (very small) patch to work on one ABORT help function as a
sample.
The reason why I post this is, to know if increasing the code-coverage (as
a task) is considered important at all (to me it is). If so, I could get
going with creating tests for more untouched lines / functions in 'make
check'.
Any other feedback is more than welcome.
(The patch is wrt to yesterday's pull)
---
Robins
Tharakan
Attachments:
commit-fa82e86application/octet-stream; name=commit-fa82e86Download
commit fa82e869fc2f500c7121f8da0a6c5676c32dedd6
Author: Robins Tharakan <robins@pobox.com>
Date: Sun Mar 10 17:08:55 2013 +0530
Add test to check whether help message for ABORT shows up
diff --git a/src/test/regress/expected/psql_help.out b/src/test/regress/expected/psql_help.out
new file mode 100644
index 0000000..df9c80d
--- /dev/null
+++ b/src/test/regress/expected/psql_help.out
@@ -0,0 +1,11 @@
+--
+-- Tests for psql's help section, that aren't closely connected to any
+-- specific server features
+--
+-- \h ABORT should show the ABORT help command
+\h ABORT
+Command: ABORT
+Description: abort the current transaction
+Syntax:
+ABORT [ WORK | TRANSACTION ]
+
diff --git a/src/test/regress/parallel_schedule b/src/test/regress/parallel_schedule
index 2af28b1..7991328 100644
--- a/src/test/regress/parallel_schedule
+++ b/src/test/regress/parallel_schedule
@@ -88,7 +88,7 @@ test: privileges security_label collate matview
# ----------
# Another group of parallel tests
# ----------
-test: alter_generic misc psql
+test: alter_generic misc psql psql_help
# rules cannot run concurrently with any test that creates a view
test: rules
diff --git a/src/test/regress/sql/psql_help.sql b/src/test/regress/sql/psql_help.sql
new file mode 100644
index 0000000..c4f6279
--- /dev/null
+++ b/src/test/regress/sql/psql_help.sql
@@ -0,0 +1,7 @@
+--
+-- Tests for psql's help section, that aren't closely connected to any
+-- specific server features
+--
+
+-- \h ABORT should show the ABORT help command
+\h ABORT
Robins wrote:
Hi,
I was checking code-coverage of 'make check' and saw that the regression
tests don't touch files like psql_help.c at all (read 0%).Attached is a (very small) patch to work on one ABORT help function as a
sample.The reason why I post this is, to know if increasing the code-coverage (as
a task) is considered important at all (to me it is). If so, I could get
going with creating tests for more untouched lines / functions in 'make
check'.
I think increasing coverage is a good thing. But psql help? *shrug*
backend code is far more interesting and useful.
Another thing to keep in mind is that there are some corner cases that
are interesting to test that might not necessarily show up in a coverage
chart -- for example how stuff behaves in the face of concurrent
processes, or when various counters wrap around.
Peter Eisentraut has set up a Jenkins instance that publishes coverage
info.
http://pgci.eisentraut.org/jenkins/job/postgresql_master_coverage/Coverage/
(I think he only has it running "make check"; doing the isolation tests
probably raises percentages a bit).
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thanks Alvaro!
The thought of psql_help purely because it was the easiest at that time.
Since I've just begun my understanding of the code is barely negligible.
I began working on SEQUENCE related tests thereafter and hopefully would
move to more complicated tests in time. Peter's link is obviously helpful
but since I end up doing make check ~100 of times a day, for now its useful
only to cross-check how much code is uncommitted :)
Robins
On 11 March 2013 09:16, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Show quoted text
I think increasing coverage is a good thing. But psql help? *shrug*
backend code is far more interesting and useful.Another thing to keep in mind is that there are some corner cases that
are interesting to test that might not necessarily show up in a coverage
chart -- for example how stuff behaves in the face of concurrent
processes, or when various counters wrap around.Peter Eisentraut has set up a Jenkins instance that publishes coverage
info.
http://pgci.eisentraut.org/jenkins/job/postgresql_master_coverage/Coverage/
(I think he only has it running "make check"; doing the isolation tests
probably raises percentages a bit).