String comparison method (compare.glue) doesn't work with testthat 3rd edition

[tobiasziegler]

I was just setting up tests in a new project using testthat 3e and found that comparing a string made using glue doesn't match an equivalent character string.

The change in testthat to using waldo::compare means that the compare.glue method isn't called.

Here's a reprex demonstrating the difference between testthat 2e and 3e:

library(glue)
library(testthat)

a <- glue("this is a test string")
b <- "this is a test string"

test_that("glue and character strings match - testthat 2e", {
  local_edition(2)
  expect_equal(a, b)
})
#> Test passed 🎊

test_that("glue and character strings match - testthat 3e", {
  local_edition(3)
  expect_equal(a, b)
})
#> ── Failure (<text>:14:3): glue and character strings match - testthat 3e ───────
#> `a` (`actual`) not equal to `b` (`expected`).
#> 
#> `actual` is an S3 object of class <glue/character>, a character vector
#> `expected` is a character vector ('this is a test string')

testthat::compare(a, b)
#> Equal
waldo::compare(a, b)
#> `old` is an S3 object of class <glue/character>, a character vector
#> `new` is a character vector ('this is a test string')

^{Created on 2021-02-24 by the reprex package (v1.0.0)}

Workarounds for now would be to use testthat 2e (remove/omit the Config/testthat/edition: 3 line from DESCRIPTION in projects using testthat >= 3.0.0), or wrap the expected values in tests where glue creates the actual string(s) with as_glue().

But it looks like compare_proxy provides a way to override the default comparison behaviour in waldo. I'd be happy to put together a pull request if it's wanted. Thanks.

[jimhester]

Sure if you are up for putting together a pull request that would be great!

[tobiasziegler]

I did a bit of work on this but it turns out the proxy method isn't called until waldo::compare has already compared the types. Unless someone can see another way to do it (I'm far from expert), I don't think there's a way to make it so that glue-created string output and matching base strings will pass comparisons using waldo (and therefore testthat 3e).

I've noted this in the waldo issue above in case the team thinks that change can be made - if so, then I'll be happy to come back to this. Otherwise the workarounds above should deal with the issue.

[hadley]

This is now fixed in waldo, and I'm about to release it to CRAN, so if you're still interested, this would be a great time to have another go @tobiasziegler.