Skip to content
This repository was archived by the owner on Mar 26, 2026. It is now read-only.

build: execute parallel integration tests#797

Merged
gcf-merge-on-green[bot] merged 15 commits intomainfrom
execute-parallel-integration-tests
Apr 22, 2022
Merged

build: execute parallel integration tests#797
gcf-merge-on-green[bot] merged 15 commits intomainfrom
execute-parallel-integration-tests

Conversation

@olavloite
Copy link
Copy Markdown
Collaborator

@olavloite olavloite commented Apr 12, 2022

Refactors the integration tests to fix a number of problems:

  1. Too much state was kept in the abstract base class for all integration tests. This did not work properly with parameterized tests, as some state leaked from one parameter value (dialect) to another.
  2. The emulator cannot use an existing instance for testing, as it always starts without any existing instances. This is now fixed by forcing tests to used a separate instance for each test class when running on the emulator, and by fixing creation and database cleanup before/after tests.

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.

@product-auto-label product-auto-label Bot added size: s Pull request size is small. api: spanner Issues related to the googleapis/java-spanner-jdbc API. labels Apr 12, 2022
@product-auto-label product-auto-label Bot added size: m Pull request size is medium. and removed size: s Pull request size is small. labels Apr 12, 2022
@product-auto-label product-auto-label Bot added size: l Pull request size is large. and removed size: m Pull request size is medium. labels Apr 15, 2022
@product-auto-label product-auto-label Bot added size: xl Pull request size is extra large. and removed size: l Pull request size is large. labels Apr 15, 2022
@olavloite olavloite marked this pull request as ready for review April 15, 2022 10:44
@olavloite olavloite requested review from a team April 15, 2022 10:44
@olavloite olavloite changed the title build: [WIP] execute parallel integration tests build: execute parallel integration tests Apr 15, 2022
@olavloite olavloite requested review from ansh0l and mpeddada1 April 15, 2022 10:51
@mpeddada1
Copy link
Copy Markdown
Contributor

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.

@olavloite olavloite added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Apr 19, 2022
@yoshi-kokoro yoshi-kokoro removed the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Apr 19, 2022
Copy link
Copy Markdown
Contributor

@ansh0l ansh0l left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: indentation

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@@ -0,0 +1,64 @@
/*
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good

@Before
public void setup() {
assumeFalse(
"Emulator does not support PostgreSQL",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good

}

@Override
public Dialect getDialect() {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we make getDialect private? setup method seems to be taking care of things now

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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() {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the setup method go into ITAbstractJdbcTest class?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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")));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checking is TABLE_SCHEM the right intended string?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good

@ansh0l
Copy link
Copy Markdown
Contributor

ansh0l commented Apr 22, 2022

@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.

@olavloite
Copy link
Copy Markdown
Collaborator Author

@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.

@olavloite olavloite added the automerge Merge the pull request once unit tests and other checks pass. label Apr 22, 2022
@gcf-merge-on-green gcf-merge-on-green Bot merged commit 93a0c05 into main Apr 22, 2022
@gcf-merge-on-green gcf-merge-on-green Bot deleted the execute-parallel-integration-tests branch April 22, 2022 13:52
@gcf-merge-on-green gcf-merge-on-green Bot removed the automerge Merge the pull request once unit tests and other checks pass. label Apr 22, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

api: spanner Issues related to the googleapis/java-spanner-jdbc API. size: xl Pull request size is extra large.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants