Skip to content

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

Closed
wants to merge 16 commits into from
Closed

Conversation

kenmawer
Copy link
Contributor

@kenmawer kenmawer commented Aug 10, 2022

Note that I was unable to prompt this warning message:

Warn("xcontains duplicate values. (If being run on a column in anepi_df, did you group by relevant key variables?)")

@brookslogan
Copy link
Contributor

brookslogan commented Aug 11, 2022

  • Think you can trigger that warning + some error with
jhu_csse_daily_subset %>% 
  # group_by(geo_value) %>% 
  mutate(cases_gr = growth_rate(x = time_value,  y = cases, dup_rm=TRUE))

but without dup_rm=TRUE, it actually returns a result.... is this a bug? Do you know what the result would represent in this case?

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)
})
Copy link
Contributor

@brookslogan brookslogan Aug 11, 2022

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 methods.

Also, please test that each of the methods, log_scale settings, and na_rm settings at least run successfully.

Copy link
Contributor

@brookslogan brookslogan Aug 11, 2022

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_snapshots? I assume we'll need to take the expect_snapshot approach for some/most/all of the methods; I'm not sure, e.g., that there's a simple example where we would think the trendfilter output is obvious.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@brookslogan brookslogan Aug 17, 2022

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.

Copy link
Contributor

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?

@kenmawer kenmawer changed the title Test growth-rate Test growth_rate Aug 11, 2022
… 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
@kenmawer kenmawer requested a review from brookslogan August 11, 2022 21:51
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)
})
Copy link
Contributor

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.

Copy link
Contributor

@nmdefries nmdefries left a 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)
Copy link
Contributor

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.")
Copy link
Contributor

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.

Comment on lines +30 to +31
expect_warning() %>%
expect_error()
Copy link
Contributor

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))
Copy link
Contributor

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 NAs, so are we really testing NA-removal? Do we want

Suggested change
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)
})
Copy link
Contributor

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?

@dajmcdon
Copy link
Contributor

@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?

@nmdefries
Copy link
Contributor

@dajmcdon Thanks for the feedback. I was tagged recently so not sure what the context is here.

@brookslogan Thoughts?

@dajmcdon dajmcdon closed this Oct 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants