-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check query before fetching data from server #12
Comments
Assuming that the purpose of pytest-gee is to test packages that use the Earth Engine API (either via the Earth Engine Python client library or REST API), you may want to mock responses of the Earth Engine API so the test run without accessing Earth Engine. |
Sorry for not answering earlier but the objective is actually to check the Python API response. The problem we've been facing in the past is small changes made by the GEE behavior without notifying developers. The purpose of the lib here is to really asset the result of the server-side computation. To provide some context, this plugn is a byproduct of the geetools package that create and manipulate server side object. I really need the response to be evaluate to make sur I'm doing the right thing. I actually got an idea from a colleague on a private repo, I'll try to implement it when I have the time (you'll see it's fancy 😄) |
In this case I would suggest setting up two sets of tests:
|
ah sure this will be done in downstream packages (geetools, ipygee, pygaul... maybe more ?) |
Problem
Commercial user of GEE API get charged for its usage, so every time a test is triggered, it fetches data from server creating cost for the company. Also, it takes time to fetch data, so when trying to run a complete set of tests, it could take long to finish.
Solution
Save the query string into a file (write/read functionality can be found in geetools) and, when the test is triggered, first check if the query string is the same, if
True
then skip it, ifFalse
then fetch.Context
The version of GEE python API could be something to consider, since the structure of the query could change from version to version, thus a version check could be implemented. The version should be stored somewhere alongside the query string, so to avoid having to modify the string and for example create a new string/dict with the version code, my proposal is to write it as part of the filename, something like:
test_some_method_0-1-384.gee
Probably @tylere could have an opinion on this.
The text was updated successfully, but these errors were encountered: