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

expect_true_false_linter catches TRUE/FALSE not passed to expected #1520

Open
heavywatal opened this issue Aug 29, 2022 · 3 comments · May be fixed by #2809
Open

expect_true_false_linter catches TRUE/FALSE not passed to expected #1520

heavywatal opened this issue Aug 29, 2022 · 3 comments · May be fixed by #2809
Labels
false-positive code that shouldn't lint, but does

Comments

@heavywatal
Copy link

This false positive happens when expect_identical() is used with piping and optional arguments to waldo.

lintr::lint(linters = list(lintr::expect_true_false_linter()), text = "
library(testthat)
42 |> expect_identical(42, ignore_attr = TRUE)
")
#> <text>:3:7: warning: [expect_true_false_linter] expect_true(x) is better than expect_identical(x, TRUE)
#> 42 |> expect_identical(42, ignore_attr = TRUE)
#>       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@IndrajeetPatil
Copy link
Collaborator

Thanks for the report.

Can also reproduce with the current main branch:

library(lintr)

lint(
  text = "42 |> expect_identical(42, ignore_attr = TRUE)",
  linter = expect_true_false_linter(),
)
#> <text>:1:7: warning: [expect_true_false_linter] expect_true(x) is better than expect_identical(x, TRUE)
#> 42 |> expect_identical(42, ignore_attr = TRUE)
#>       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Created on 2022-08-29 with reprex v2.0.2

Session info
sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.2.1 (2022-06-23)
#>  os       macOS Monterey 12.5
#>  system   aarch64, darwin20
#>  ui       X11
#>  language (EN)
#>  collate  en_US.UTF-8
#>  ctype    en_US.UTF-8
#>  tz       Europe/Berlin
#>  date     2022-08-29
#>  pandoc   2.19.2 @ /usr/local/bin/ (via rmarkdown)
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package      * version    date (UTC) lib source
#>  callr          3.7.2      2022-08-22 [1] CRAN (R 4.2.0)
#>  cli            3.3.0      2022-04-25 [1] CRAN (R 4.2.0)
#>  crayon         1.5.1      2022-03-26 [1] CRAN (R 4.2.0)
#>  cyclocomp      1.1.0      2016-09-10 [1] CRAN (R 4.2.0)
#>  desc           1.4.1      2022-03-06 [1] CRAN (R 4.2.0)
#>  digest         0.6.29     2021-12-01 [1] CRAN (R 4.2.0)
#>  evaluate       0.16       2022-08-09 [1] CRAN (R 4.2.1)
#>  fansi          1.0.3      2022-03-24 [1] CRAN (R 4.2.0)
#>  fastmap        1.1.0      2021-01-25 [1] CRAN (R 4.2.0)
#>  fs             1.5.2      2021-12-08 [1] CRAN (R 4.2.0)
#>  glue           1.6.2      2022-02-24 [1] CRAN (R 4.2.0)
#>  highr          0.9        2021-04-16 [1] CRAN (R 4.2.0)
#>  htmltools      0.5.3      2022-07-18 [1] CRAN (R 4.2.1)
#>  knitr          1.40       2022-08-24 [1] CRAN (R 4.2.1)
#>  lazyeval       0.2.2      2019-03-15 [1] CRAN (R 4.2.0)
#>  lifecycle      1.0.1      2021-09-24 [1] CRAN (R 4.2.0)
#>  lintr        * 3.0.0.9000 2022-08-29 [1] local
#>  magrittr       2.0.3      2022-03-30 [1] CRAN (R 4.2.0)
#>  pillar         1.8.1      2022-08-19 [1] CRAN (R 4.2.1)
#>  pkgconfig      2.0.3      2019-09-22 [1] CRAN (R 4.2.0)
#>  processx       3.7.0      2022-07-07 [1] CRAN (R 4.2.1)
#>  ps             1.7.1      2022-06-18 [1] CRAN (R 4.2.0)
#>  purrr          0.3.4      2020-04-17 [1] CRAN (R 4.2.0)
#>  R.cache        0.16.0     2022-07-21 [1] CRAN (R 4.2.0)
#>  R.methodsS3    1.8.2      2022-06-13 [1] CRAN (R 4.2.0)
#>  R.oo           1.25.0     2022-06-12 [1] CRAN (R 4.2.0)
#>  R.utils        2.12.0     2022-06-28 [1] CRAN (R 4.2.0)
#>  R6             2.5.1.9000 2022-08-06 [1] Github (r-lib/R6@87d5e45)
#>  remotes        2.4.2      2021-11-30 [1] CRAN (R 4.2.0)
#>  reprex         2.0.2      2022-08-17 [1] CRAN (R 4.2.1)
#>  rex            1.2.1      2021-11-26 [1] CRAN (R 4.2.0)
#>  rlang          1.0.4      2022-07-12 [1] CRAN (R 4.2.1)
#>  rmarkdown      2.16       2022-08-24 [1] CRAN (R 4.2.1)
#>  rprojroot      2.0.3      2022-04-02 [1] CRAN (R 4.2.0)
#>  rstudioapi     0.14       2022-08-22 [1] CRAN (R 4.2.1)
#>  sessioninfo    1.2.2      2021-12-06 [1] CRAN (R 4.2.0)
#>  stringi        1.7.8      2022-07-11 [1] CRAN (R 4.2.1)
#>  stringr        1.4.1      2022-08-20 [1] CRAN (R 4.2.1)
#>  styler         1.7.0.9001 2022-08-24 [1] local
#>  tibble         3.1.8      2022-07-22 [1] CRAN (R 4.2.1)
#>  utf8           1.2.2      2021-07-24 [1] CRAN (R 4.2.0)
#>  vctrs          0.4.1      2022-04-13 [1] CRAN (R 4.2.0)
#>  withr          2.5.0      2022-03-03 [1] CRAN (R 4.2.0)
#>  xfun           0.32       2022-08-10 [1] CRAN (R 4.2.1)
#>  xml2           1.3.3      2021-11-30 [1] CRAN (R 4.2.0)
#>  xmlparsedata   1.0.5      2021-03-06 [1] CRAN (R 4.2.0)
#>  yaml           2.3.5      2022-02-21 [1] CRAN (R 4.2.0)
#> 
#>  [1] /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library
#> 
#> ──────────────────────────────────────────────────────────────────────────────

@IndrajeetPatil IndrajeetPatil added the false-positive code that shouldn't lint, but does label Aug 29, 2022
@MichaelChirico
Copy link
Collaborator

MichaelChirico commented Aug 29, 2022 via email

@heavywatal
Copy link
Author

I think piping/chaining expectations is not so uncommon because expect_*() functions are suppose to return the input invisibly to achieve this, and it is officially documented:
https://testthat.r-lib.org/articles/custom-expectation.html#invisibly-return-the-input

My use case is testing custom methods for round-trip conversion between array and data.frame like this:

x |>
  as.array() |>
  expect_type("integer") |>
  expect_length(3L ** 3L) |>  # waiting for expect_shape() r-lib/testthat#1423
  expect_setequal(c(0L, 1L)) |>
  as.data.frame() |>
  expect_identical(x)

@MichaelChirico MichaelChirico linked a pull request Mar 4, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
false-positive code that shouldn't lint, but does
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants