build: execute parallel integration tests#797
Conversation
|
Thanks so much for looking into this @olavloite! This looks good on my end. The Native Image tests are failing because we need to specify some system properties through the maven surefire plugin - this will be addressed in https://github.com/googleapis/java-spanner-jdbc/pull/796/files. Will let @ansh0l do a final review. |
ansh0l
left a comment
There was a problem hiding this comment.
LGTM with few minor nits. Please take a look.
| ColTimestamp TIMESTAMP NOT NULL, | ||
| ColCommitTS TIMESTAMP NOT NULL OPTIONS (allow_commit_timestamp=true), | ||
| ColNumeric NUMERIC NOT NULL, | ||
| ColJson JSON NOT NULL, |
| @@ -0,0 +1,64 @@ | |||
| /* | |||
| @Before | ||
| public void setup() { | ||
| assumeFalse( | ||
| "Emulator does not support PostgreSQL", |
| } | ||
|
|
||
| @Override | ||
| public Dialect getDialect() { |
There was a problem hiding this comment.
should we make getDialect private? setup method seems to be taking care of things now
There was a problem hiding this comment.
No, not entirely. Some of the tests are uni-dialect (so only PG or only GoogleSQL), while others are parameterized. The default implementation is uni-dialect and always returns GoogleSQL. This method is then overridden in the test classes that either use only PG or are parameterized. So we cannot make it private.
| private Database database; | ||
|
|
||
| @Before | ||
| public void setup() { |
There was a problem hiding this comment.
Should the setup method go into ITAbstractJdbcTest class?
There was a problem hiding this comment.
I decided to move that away from the abstract base class, as it was one of the main reasons that things were not working properly. The data model that is created by the different test classes is different, and that went wrong for the parameterized test classes, as they need to take the dialect into account as well. So this solves a lot of hassle for those tests at the expense of a little code duplication.
| @@ -27,10 +27,10 @@ | |||
| import static org.junit.Assume.assumeFalse; | |||
|
|
|||
There was a problem hiding this comment.
looks good (with same observations as for setup method before
| assertThat(rs.getString("TABLE_CATALOG"), is(equalTo(DEFAULT_CATALOG))); | ||
| if (!EmulatorSpannerHelper.isUsingEmulator()) { | ||
| assertThat(rs.next(), is(true)); | ||
| assertThat(rs.getString("TABLE_SCHEM"), is(equalTo("SPANNER_SYS"))); |
There was a problem hiding this comment.
Just checking is TABLE_SCHEM the right intended string?
There was a problem hiding this comment.
Good point. Yes, this is intentional. That is one of the strange things about the JDBC definition. They decided to abbreviate one of the column names, and did so by removing only the last letter. Or someone made a typo 25 years ago, and it could never be fixed.... I guess we'll never know.
| } | ||
| } | ||
|
|
||
| private static final String DEFAULT_KEY_FILE = null; |
|
@olavloite : The resource_exhausted errors should not be occuring any more, if they are, let me / @rajatbhatta know - they are working on a longer term fix for that. |
Thanks! The last run executed without problems, so hopefully it stays that way. |
Refactors the integration tests to fix a number of problems:
In addition the integration tests were not executed by Kokoro, as they were skipped in the default test execution. All integration tests are now executed by default.
@ansh0l @mpeddada1
The integration tests are (probably) still failing, but that is because the default test instance (projects/gcloud-devel/instances/spanner-testing-east1) is clogged with old (?) test databases that have not been cleaned up. Some test cases therefore currently fail with an error that they cannot create another database, as the max of 100 databases per instance has been reached. I don't have access to the affected instance, so I cannot clean it up. Hopefully one of you has access to it.
I've verified that the integration tests work on a different instance.