Forthcoming ggplot2 release and ggstatsplot

[paleolimbot]

We're in the process of preparing a ggplot2 release. As part of the release process, we run the R CMD check on packages that use ggplot2 to make sure we don't accidentally break code for downstream packages.

In running the R CMD check on ggstatsplot, we identified the following issue:

• checking tests ...

   ERROR
  Running the tests in ‘tests/testthat.R’ failed.
  Last 13 lines of output:
    as.character(df2$value[[35]][1]) not identical to "5pt".
    1/1 mismatches
    x[1]: "NULL"
    y[1]: "5pt"
    
    ══ testthat results  ═══════════════════════════════════════════════════════════
    OK: 21 SKIPPED: 184 WARNINGS: 0 FAILED: 5
    1. Failure: `theme_pie()` works (@test_theme_ggstatsplot.R#65) 
    2. Failure: `theme_pie()` works (@test_theme_ggstatsplot.R#66) 
    3. Failure: `theme_pie()` works (@test_theme_ggstatsplot.R#67) 
    4. Failure: `theme_pie()` works (@test_theme_ggstatsplot.R#68) 
    5. Failure: `theme_pie()` works (@test_theme_ggstatsplot.R#69) 
    
    Error: testthat unit tests failed
    Execution halted
  

These failures are because ggstatsplot is testing the internal structure of ggplot object. This is, in short, a bad idea. In particular, this practice makes it difficult for us to improve ggplot2 without causing your tests to fail.

We suggest testing the output of ggplot2 in using the vdiffr package, which is a tool to manage visual test cases (this is how we test ggplot2). If changes in ggplot2 or your code introduce a change in the visual output of a ggplot, tests will fail when you run them locally. You can use vdiffr as follows:

test_that("output of ggplot() is stable", {
  vdiffr::expect_doppelganger("A blank plot", ggplot())
})

As a side note, including library() calls within test_that() may result in unexpected behaviour in other tests. In general, your tests should pass without ggplot2 attached.

Let me know if I can help! We are hoping to release the next version of ggplot2 in the next two weeks.