feat: add fragment tests #1056
Merged
feat: add fragment tests #1056
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
software-dov
requested review from
tseaver,
parthea,
busunkim96,
arithmetic1728 and
a team
google-cla
bot
added
the
cla: yes
Fragment tests are defined by a small proto file describing an API surface with characteristics such that it is desirable to test the generated surface for correctness or to prevent regressions. As part of a fragment test, the generator is run on a fragment to create a GAPIC library for the fragment. The generated unit tests for the fragment are then executed to test the surface.
software-dov
force-pushed
the
fragment-tests
branch
from
602aa74
to
307a95e
Compare
Within a session, e.g. Python 3.9, all fragment GAPICs are generated and tested concurrently.
software-dov
force-pushed
the
fragment-tests
branch
from
307a95e
to
0033054
Compare
This was
linked to
issues
Oct 29, 2021
busunkim96
approved these changes
Nov 1, 2021
| option java_package = "com.google.api"; | ||
| option objc_class_prefix = "GAPI"; | ||
|
|
||
| extend google.protobuf.MethodOptions { |
There was a problem hiding this comment.
Where are these proto files from?
There was a problem hiding this comment.
I copied them from googleapis and protobuf. My original idea was something complicated involving a hand-rolled semaphore/caching system to pull those repos as dependencies before running the fragment tests. I realized that was way too complicated, however, and just copied the three files I needed for these fragments.
gcf-merge-on-green bot
pushed a commit
that referenced
this pull request
Nov 1, 2021
🤖 I have created a release \*beep\* \*boop\* --- ## [0.55.0](https://www.github.com/googleapis/gapic-generator-python/compare/v0.54.0...v0.55.0) (2021-11-01) ### Features * add fragment tests ([#1056](https://www.github.com/googleapis/gapic-generator-python/issues/1056)) ([9d9b33d](https://www.github.com/googleapis/gapic-generator-python/commit/9d9b33dadf587a6d0b09031edeea597d6d2eae62)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
This was referenced Jan 18, 2022
This was referenced Jan 26, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fragment tests are defined by a small proto file describing an API
surface with characteristics such that it is desirable to test the
generated surface for correctness or to prevent regressions.
As part of a fragment test, the generator is run on a fragment to
create a GAPIC library for the fragment. The generated unit tests
for the fragment are then executed to test the surface.
Includes fragment tests and fixes for #413 and #414 as well as fragment tests for various other previously fixed issues.
Note: the parallelization of the fragment tests is currently a standalone commit and can be removed. It dramatically speeds up execution, however, since most of the time spent per fragment is waiting on I/O or subprocesses.