Skip to content

Improve test coverage #93

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
dshemetov opened this issue Apr 29, 2023 · 3 comments · Fixed by #118
Closed

Improve test coverage #93

dshemetov opened this issue Apr 29, 2023 · 3 comments · Fixed by #118
Assignees
Labels
help wanted Extra attention is needed P1 medium priority

Comments

@dshemetov
Copy link
Contributor

dshemetov commented Apr 29, 2023

Current coverage looks like:

File	       Lines	Relevant Covered Missed	Hits / Line	Coverage
R/covidcast.R	178	94	72	22	275	76.60%
R/epidatacall.R	270	89	74	15	21	83.15%
R/endpoints.R	1679	810	796	14	2	98.27%
R/model.R	181	95	94	1	186	98.95%
R/check.R	51	28	28	0	67	100.00%
R/request.R	44	18	18	0	10	100.00%
R/auth.R	35	18	18	0	8	100.00%
R/utils.R	19	6	6	0	47	100.00%

Generated with

library(covr)
report(file="test-report.html")
@dshemetov dshemetov added help wanted Extra attention is needed P1 medium priority labels Apr 29, 2023
@dsweber2 dsweber2 self-assigned this May 17, 2023
@dsweber2
Copy link
Contributor

dsweber2 commented May 23, 2023

Notes on what's not covered yet:

the TLDR broad categories of untested:

  • printing utilities
  • some fetch errors
  • some http error codes
  • endpoint errors (mostly issues/lag being mutually exclusive
  • if statements which had a case missing

going to put two categories per file: to be tested and not to be tested. Feel free to move specific examples around as needed

covidcast.R:

to be tested:

not to be tested:

request.R:

to be tested:

not to be tested:

  • (just to make this a list)

epidatacall.R:

to be tested:

not to be tested:

model.R:

not to be tested:

endpoints.R:

not to be tested:

@dsweber2
Copy link
Contributor

dsweber2 commented Jun 1, 2023

In epidatacall.R fetch_classic, I don't think the check for response_content$result != 1 is the right way to go about this.
I think result is never going to be -1 or -2, as http errors 400, 401, 403, 405, 414, and 500 are all thrown as R errors earlier in request.R, while other errors make no guarantees of returning something parseable by httr::content and/or jsonlite::fromJSON. An example:

test_that("non-enumerated errors are passed up the chain", {
  response <- httr::RETRY("GET",
    url = "https://httpbin.org/status/418",
    query = list(),
    terminate_on = c(400, 401, 403, 405, 414, 500),
    http_headers,
    httr::authenticate("epidata", get_auth_key())
  ) %>% readr::write_rds(testthat::test_path("data/test-do_request-httpbin418.rds"))
  local_mocked_bindings(request_impl = function(...) readRDS(testthat::test_path("data/test-do_request-httpbin418.rds")))
  epidata_call <- delphi(system = "ec", epiweek = 201501)
  expect_error(epidata_call %>% fetch_classic(), class = "epidata_error")
})

So I'm leaving that one unchecked and untested for now

@dshemetov
Copy link
Contributor Author

dshemetov commented Jun 9, 2023

So there are 4 epidata status codes I know:

  • 1 success
  • 2 truncated
  • -2 no results
  • -1 generic error (e.g. messed up query params)

All of these come out of a non-error HTTP response.

But yes, any of the other HTTP error codes come prior to epidata status codes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed P1 medium priority
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants