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

Upgrade testthat to use 3rd edition #656

Closed
nikolas-burkoff opened this issue Jul 29, 2022 · 7 comments · Fixed by #801
Closed

Upgrade testthat to use 3rd edition #656

nikolas-burkoff opened this issue Jul 29, 2022 · 7 comments · Fixed by #801
Assignees

Comments

@nikolas-burkoff
Copy link
Contributor

From https://github.com/insightsengineering/coredev-tasks/issues/154

Part of insightsengineering/NEST-roadmap#65

@Melkiades
Copy link
Contributor

I think we already do this right @nikolas-burkoff ?

@nikolas-burkoff
Copy link
Contributor Author

We have if the DESC file has Config/testthat/edition: 3 in https://testthat.r-lib.org/articles/third-edition.html#activating

@Melkiades
Copy link
Contributor

I think it is worth it. Error messages with waldo are much more informative and warnings are better handled. Is testthat at version >3 on our platforms @arkadiuszbeer ? If so I suggest to complete this

@arkadiuszbeer
Copy link
Contributor

@Melkiades yes, we are using [email protected]

@Melkiades Melkiades self-assigned this Dec 1, 2022
@Melkiades
Copy link
Contributor

I was wondering what should we do in case of warnings. ATM it does return the warning and not the output. For example:

>   # Check with LOW abnormality.
>   result <- testthat::expect_warning(
+     s_count_abnormal_by_baseline(
+       df = df,
+       .var = "myrange",
+       abnormal = "LOW",
+       variables = list(id = "myid", baseline = "mybase")
+     )
+   ) %>% suppressWarnings()
> result
<simpleWarning in as_factor_keep_attributes(df[[.var]], na_level = na_level): automatically converting character variable df[[.var]] to factor, better manually convert to factor to avoid failures>

Should I make a wrapper of expect_warning like custom_expect_warning that preserves the old behavior with a double call or checking the piece twice in the test itself? I do not see other solutions

@Melkiades
Copy link
Contributor

btw there are hundreds of errors :D

@Melkiades
Copy link
Contributor

talking with @shajoezhu and due to the amount of work needed to fix this, we put it back to the stack to be dealt with during next increment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants