Skip to content
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

download.AmerifluxLBL: respect overwrite argument #3382

Merged
merged 5 commits into from
Sep 23, 2024

Conversation

infotroph
Copy link
Member

Description

Fixes #3381

@meetagrawal09 This is my first time using the "new" testthat mocking functions, so I'd appreciate your feedback on the approach. If I'm doing it all wrong, let's fix it now before I develop bad habits ;)

Motivation and Context

Review Time Estimate

  • Immediately
  • Within one week
  • When possible

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My change requires a change to the documentation.
  • My name is in the list of CITATION.cff
  • I have updated the CHANGELOG.md.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

amf_var_info = \(...) data.frame(
Site_ID = "US-Akn",
BASE_Version = "6-5"),
.package = "amerifluxr"
Copy link
Member Author

Choose a reason for hiding this comment

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

@meetagrawal09 Can you comment in general on whether my mocking approach makes sense here, and specifically check my reasoning for going against the testthat recommendations?

The testthat docs advise not mocking objects from other namespaces because [my paraphrasings]: (1) it'll affect anything else that calls into that namespace during the life of the mock, even if from outside the code under test, and (2) the point of namespaces is to be sealed, dangit. They recommend instead to either import the functions in question or to encapsulate them in wrapper functions and then mock those.

For this case both of those options seem like a big extra layer of indirection and I don't see any risk of the mock affecting unintended code. Thoughts?

Copy link
Collaborator

@meetagrawal09 meetagrawal09 Sep 18, 2024

Choose a reason for hiding this comment

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

I think that the approach you have taken by mocking these internal functions which take care of the data download is actually the right way to test the emphasis of overwrite. Honestly when I write unit tests the motive is to make them run as isolated as possible and mocking functions that deal with a third party data download is one such step towards isolation.


# Case 2: overwrite existing download
dl_akn(overwrite = TRUE)
expect_gt(file.mtime(zippath), ziptime)
Copy link
Collaborator

@meetagrawal09 meetagrawal09 Sep 18, 2024

Choose a reason for hiding this comment

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

The approach you took for checking if the overwrite option is actually working seems clean. File modification time is definitely a good way to go about it.

With that said I would have done something like using mockery to mock the download function to return different data (some random mock text) for subsequent calls. Then we check if the file text was indeed updated when overwrite was set to true on the function call.

@infotroph infotroph merged commit d136f48 into PecanProject:develop Sep 23, 2024
16 of 22 checks passed
@infotroph infotroph deleted the amfLBL-fix branch September 23, 2024 21:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

AmerifluxLBL: overwrite = FALSE clobbers raw zip files, overwrite = TRUE fails treating path as URL
3 participants