search

vascobnunes / fetchLandsatSentinelFromGoogleCloud

Find and download Landsat and Sentinel-2 data from the public Google Cloud
https://vascobnunes.github.io/fetchLandsatSentinelFromGoogleCloud/
MIT License
53 stars 23 forks source link

Create some automatic tests #49

Open vascobnunes opened 5 years ago

vascobnunes commented 3 years ago

@matt-bernstein do you have something we could use for this issue in the wishlist?

matt-bernstein commented 3 years ago

What I'm familiar with for python projects is pytest+xdoctest. This style of testing makes each function self-documenting and self-testing. You can see an example of a function I wrote in this style here, even though pytest is not active in this repo: https://github.com/vascobnunes/fetchLandsatSentinelFromGoogleCloud/blob/master/fels/sentinel2.py#L181

Basically, running pytest searches your repo for those >>> blocks and runs all code in them. In this way each function is documented and tested at the same time. You can also write extra tests that are not tied to a specific function, but I have found it natural to make all or almost all tests into doctests.

xdoctest is a drop-in replacement for python's normal doctests with more sophisticated options; for example, you can specify that a test needs to download a file, so it should only be run if there is an active network connection.

The next step after that would be to create a Github CI action that automatically runs tests when a commit is made. This would make it easy to verify PRs by checking that they pass all tests before merging them to master. You can also use CI to do linting using flake8, black, yapf, etc.

tox would be the "more serious" option for testing, but I have no experience with it.

I can start a PR that sketches this out next week if you are interested.

vascobnunes commented 3 years ago

That would be great! I'm already using the Github CI action feature to put each new release on pypi. If we could have a set of tests running automatically for each time a commit is made, would be a good way at least to prevent any regression.

Erotemic commented 2 years ago

This is effectively done. There are more tests that could be added, but the main use cases are covered. (The trick is to balance CI time because testing different code paths requires downloading a lot of data!)