-
Notifications
You must be signed in to change notification settings - Fork 8
Test growth_rate #197
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
Test growth_rate #197
Conversation
…nd y as c(1,1:19), for example, won't work.
jhu_csse_daily_subset %>%
# group_by(geo_value) %>%
mutate(cases_gr = growth_rate(x = time_value, y = cases, dup_rm=TRUE)) but without |
expect_error(growth_rate(x=1:20,y=1:20,x0=21), | ||
"`x0` must be a subset of `x`.") | ||
expect_error(growth_rate(x=1:20,y=1:20,x0=c(1,3)),NA) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add another test for the actual values coming out? E.g., construct a simple example where the growth rate should be obvious, and test that we calculate that obvious value. At least for some of the method
s.
Also, please test that each of the method
s, log_scale
settings, and na_rm
settings at least run successfully.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you can't construct an example where you think you know what the output should be, maybe throw in some testthat::expect_snapshot
s? I assume we'll need to take the expect_snapshot
approach for some/most/all of the method
s; I'm not sure, e.g., that there's a simple example where we would think the trendfilter output is obvious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
expect_snapshot
creates a new file for snapshots and does something that doesn't seem inherently helpful. All it does it checks for errors from my experience; however, that doesn't seem to be any better than doing expect_error
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kenmawer I think the point here is to test that the correct calculations are occurring when arguments are correctly specified, not just that errors happen when the inputs are wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I already added a few tests for calculations. I would suspect that for some of the other methods, it would be too complicated to be able to verify the outputted numbers. It also depends on what you mean by "correct calculations," whether it's merely getting the right number of cells or getting those exact numbers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it's likely too complicated to verify the output numbers [for the complex settings like using trend filtering], that's why I suggested expect_snapshot
. When you first run it, it saves the current output to a _snaps directory, which you would then commit (make sure that the test is constructed so that this file is very small; we don't want to bloat the repo), and then later, when we run the snapshot test again, it will detect the file in the _snaps directory and compare against it. If we inadvertently change the output behavior, this test will catch it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like of the requested
test that each of the methods, log_scale settings, and na_rm settings at least run successfully
only the method outputs are left -- is that correct?
…nished). Also noted that `rel_change` is the default method for estimation.
…ailed to properly eliminate NA's.
… hand editing. Merge branch 'main' of https://github.com/cmu-delphi/epiprocess into km-test-growth_rate # Conflicts: # man/epi_archive.Rd # man/epix_merge.Rd
expect_error(growth_rate(x=1:20,y=1:20,x0=21), | ||
"`x0` must be a subset of `x`.") | ||
expect_error(growth_rate(x=1:20,y=1:20,x0=c(1,3)),NA) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kenmawer I think the point here is to test that the correct calculations are occurring when arguments are correctly specified, not just that errors happen when the inputs are wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some questions about desired behavior and some about the state of previous review comments.
@@ -145,7 +146,7 @@ growth_rate = function(x = seq_along(y), y, x0 = x, | |||
|
|||
# Remove NAs if we need to | |||
if (na_rm) { | |||
o = !(is.na(x) & is.na(y)) | |||
o = !is.na(x) & !is.na(y) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Is this a bug fix? The new version of this line doesn't mean the same thing as the old version.
suggestion: I'm assuming the new version is desired behavior (keeping only pairs of obs in x and y when both values are available), but the comment "# Remove NAs if we need to" is very ambiguous. Recommend making the goal more explicit.
test_that("Test error throwing",{ | ||
# Error cases | ||
expect_error(growth_rate(x=1:3,y=1:4), | ||
"`x` and `y` must have the same length.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion [non-blocking]: Probably beyond scope here, but it would be nice if the errors and warnings in growth_rate
had classes so we could check for that rather than message wording, which is liable to change.
expect_warning() %>% | ||
expect_error() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: It's hard to tell what this is doing. If we want to check for both a warning and an error, run this twice with each expect_*
. If we're trying to do something else, I don't understand.
}) | ||
|
||
test_that("Running different methods with NA removal won't fail",{ | ||
for (m in methods) expect_false(NA %in% gr(method = m,x0=1:5)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: x0
doesn't contain any NA
s, so are we really testing NA
-removal? Do we want
for (m in methods) expect_false(NA %in% gr(method = m,x0=1:5)) | |
for (m in methods) expect_false(NA %in% gr(method = m,x0=c(1:5, NA))) |
?
expect_error(growth_rate(x=1:20,y=1:20,x0=21), | ||
"`x0` must be a subset of `x`.") | ||
expect_error(growth_rate(x=1:20,y=1:20,x0=c(1,3)),NA) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like of the requested
test that each of the methods, log_scale settings, and na_rm settings at least run successfully
only the method outputs are left -- is that correct?
@nmdefries I'm not sure whether we shouldn't just close this at this point. Maybe investigate if the possible bug fix is needed, but close without merging? |
@dajmcdon Thanks for the feedback. I was tagged recently so not sure what the context is here. @brookslogan Thoughts? |
Note that I was unable to prompt this warning message:
Warn("
xcontains duplicate values. (If being run on a column in an
epi_df, did you group by relevant key variables?)")