test: assume integer datetimes for timestamp tests

[grzm]

Float timestamp equality comparisons like comparisons with any float
are problematic if they don't take into account their imprecise
nature. Some timestamp tests produce false negative failures for
servers compiled with float timestamps. Use JUnit assumptions to skip
these tests if the server doesn't have integer datetimes.

GetObject310Test and SetObject310Test still produce these false
negative failures. Failing assumptions in these tests throw
AssumptionViolationException rather than skipping the tests. This
may be due to these tests extending BaseTest which extends
junit.framework.TestCase rather than being treated as JUnit 4
tests. Leave these failing tests as-is for now as it's the existing
behavior, and throwing these exceptions exposes an issue with the test
setup rather than testing JDBC behavior.

This addresses #12 in part in
that it omits (most of) the failing tests, though it leaves these
timestamp behaviors untested under float timestamps, which was the
default prior to PostgreSQL 8.4.

[codecov-io]

Codecov Report

Merging #873 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             master    #873      +/-   ##
===========================================
+ Coverage     65.69%   65.7%   +<.01%     
- Complexity     3544    3545       +1     
===========================================
  Files           166     166              
  Lines         15253   15253              
  Branches       2474    2474              
===========================================
+ Hits          10021   10022       +1     
  Misses         4052    4052              
+ Partials       1180    1179       -1

[grzm]

I'm not sure how to interpret the code coverage reduction. It shows changes in files (PgStatement.java and CopyManager.java) not included in the request:

https://codecov.io/gh/pgjdbc/pgjdbc/compare/c1d743f2408df8b377bc9d8440717541a5b627e3...574daad2d2ccabf9a51b36de0af4716aa41fea52/changes

Adding the assumptions will in effect cause some branches to be skipped in some environments (after all, that's kind of the point of using assumptions), but it's not clear to me how this pull request affects these branches. Any guidance appreciated.

[vlsi]

I'm not sure how to interpret the code coverage reduction

Same thing for me. I don't know how to setup codecov better.

[vlsi]

Am I right this is to "heal" tests agains 8.2?

[grzm]

I came across it when running tests for 8.3. I haven't run it against 8.2 locally, though I don't know why it wouldn't work there either. I'm not familiar with testing issues under 8.2.

[vlsi]

I came across it when running tests for 8.3. I haven't run it against 8.2 locally.

We have a Travis job testing against 8.2
And it looks like there are just two test left

Failed tests: 
  AutoRollbackTestSuite.run:256->executeSqlSuccess:323 autosave=NEVER, thus the transaction should be killed
Tests in error: 
  ResultSetTest.testgetBadBoolean:306->testBadBoolean:312 » PSQL ERROR: type "uu...

[grzm]

I've added a pull request for the skipping UUID on 8.2. UUID was added in 8.3.

#874

[grzm]

I've submitted a PR that fixes the ResultSetTest error in the 8.2 builds:

#876

[grzm]

Regarding the coverage regression, I haven't been able to figure out the cause. From what I can tell, the Debian packages used in the Travis builds all include --enable-integer-datetimes, so the assumptions should have no effect on outcome of the tests at all--they should effectively be no-ops. It would make sense if they were skipping previously failing or erring tests, but that's not the case from what I can tell.

Regardless, it appears that the previous coverage was accidental rather than deliberate, so the regression may not be meaningful in the sense that no tests that were intended to exercise the code were removed. Unfortunately my understanding of PgStatement.java--and the branch at Line 903--isn't sufficient to provide either an explanation of what changed with the given code or what test would cover the line.

pgjdbc/pgjdbc/src/main/java/org/postgresql/jdbc/PgStatement.java

Line 903 in 73bc3c1

return false;

[vlsi]

Please add if (con == null) { throw new NullPointerException("Connection is null"); } kind of check to avoid silent failures.

[vlsi]

This has just been removed (see 0221f93 ), please do not resurrect it.

[grzm]

Thanks!