test: assume integer datetimes for timestamp tests #873
Conversation
Codecov Report
@@ 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 |
I'm not sure how to interpret the code coverage reduction. It shows changes in files ( 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. |
Same thing for me. I don't know how to setup codecov better. |
Am I right this is to "heal" tests agains 8.2? |
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. |
We have a Travis job testing against 8.2
|
I've added a pull request for the skipping UUID on 8.2. UUID was added in 8.3. |
I've submitted a PR that fixes the ResultSetTest error in the 8.2 builds: |
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 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. |
@@ -660,6 +660,13 @@ public static boolean isProtocolVersion(Connection con, int version) { | |||
return false; | |||
} | |||
|
|||
public static boolean haveIntegerDateTimes(Connection con) { | |||
if (con instanceof PgConnection) { |
vlsi
Jul 23, 2017
Member
Please add if (con == null) { throw new NullPointerException("Connection is null"); }
kind of check to avoid silent failures.
Please add if (con == null) { throw new NullPointerException("Connection is null"); }
kind of check to avoid silent failures.
@@ -664,6 +664,28 @@ public static boolean haveMinimumJVMVersion(String version) { | |||
return (jvm.compareTo(version) >= 0); | |||
} | |||
|
|||
@Deprecated | |||
public static boolean isProtocolVersion(Connection con, int version) { |
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. 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.
Thanks! |
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. This addresses pgjdbc#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.
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.