This PR adds a few tests for the Variables class. It doesn't cover all the available arguments, but it adds the following tests:
the .avail() function, reading from a local file
the .avail() function, using an order result
the .append() function with the defaults flag set to True
the .remove() function for all
the .append() function when given a vars_list argument
How it was Changed
A test_variables.py file already existed, so I added additional tests there. For expected outputs longer than a few lines the output is saved in a txt or json file within the expected_outputs folder. These are read into a Python object during the test and compared to the icepyx produced result.
For the test using a local file I saved the local file in a test_data folder. I used an ATL06 product because it was small (less than 8MB). The Variables object that was created using this dataset was created as a pytest.fixture, to avoid repeating the class initiation code multiple times.
How to test it
I actually couldn't get all the tests to run, so I was only testing the test_variables.py file. To run the tests I moved into the tests folder and ran pytest test_variables.py.
Notes / Questions
Earthdata Login
In line 53 of test_variables.py I login to NASA Earthdata. This works because I have a .netrc file saved in my environment, so anyone else who runs these tests will need to have that setup as well. It looks like we maybe have some testing CI setup, so I assume that this method of logging in will fail. How do we deal with logins in CI right now? Do we already have CI EDL credentials stored in GH Secrets?
Assuming a Query will return consistently
In line 57 of test_variables.py there is a sort of awkward check to make sure that the Query only returned one granule. I can't come up with any real reason why that would ever change, but I wasn't sure. Do we feel quite certain that past granules (from 2019) won't be added (in which case I'd remove the if statement), or is it worth it to keep that check?
Context
(As a note for you @JessicaS11 I made this PR because I was starting to work on the getvars branch and thought this would provide a baseline for what the Variables module does right now when local files. When thegetvars branch enables variable search with cloud data I think ideally the calls tested here will still work swimmingly when given an s3 url instead of a local filepath.)
What was Changed
This PR adds a few tests for the Variables class. It doesn't cover all the available arguments, but it adds the following tests:
.avail()
function, reading from a local file.avail()
function, using an order result.append()
function with thedefaults
flag set to True.remove()
function for all.append()
function when given avars_list
argumentHow it was Changed
A
test_variables.py
file already existed, so I added additional tests there. For expected outputs longer than a few lines the output is saved in atxt
orjson
file within theexpected_outputs
folder. These are read into a Python object during the test and compared to theicepyx
produced result.For the test using a local file I saved the local file in a
test_data
folder. I used an ATL06 product because it was small (less than 8MB). TheVariables
object that was created using this dataset was created as apytest.fixture
, to avoid repeating the class initiation code multiple times.How to test it
I actually couldn't get all the tests to run, so I was only testing the
test_variables.py
file. To run the tests I moved into thetests
folder and ranpytest test_variables.py
.Notes / Questions
Earthdata Login
In line 53 of
test_variables.py
I login to NASA Earthdata. This works because I have a.netrc
file saved in my environment, so anyone else who runs these tests will need to have that setup as well. It looks like we maybe have some testing CI setup, so I assume that this method of logging in will fail. How do we deal with logins in CI right now? Do we already have CI EDL credentials stored in GH Secrets?Assuming a Query will return consistently
In line 57 of
test_variables.py
there is a sort of awkward check to make sure that the Query only returned one granule. I can't come up with any real reason why that would ever change, but I wasn't sure. Do we feel quite certain that past granules (from 2019) won't be added (in which case I'd remove the if statement), or is it worth it to keep that check?Context
(As a note for you @JessicaS11 I made this PR because I was starting to work on the
getvars
branch and thought this would provide a baseline for what the Variables module does right now when local files. When thegetvars
branch enables variable search with cloud data I think ideally the calls tested here will still work swimmingly when given an s3 url instead of a local filepath.)