issues with no long doubles

[topepo]

BDR sent a message complaining that a test case fails for a stan model when long doubles are disabled:

  Running ‘testthat.R’ [60s/67s]
 [60s/67s] ERROR
Running the tests in ‘tests/testthat.R’ failed.
Complete output:
  > library(testthat)
  > library(parsnip)
  > 
  > test_check("parsnip")
  ── 1. Failure: stan intervals (@test_linear_reg_stan.R#119)  ───────────────────
  confidence_parsnip$.pred_upper not equivalent to `ci_upper`.
  3/5 mismatches (average diff: 6.9e-07)
  [1] 5.10 - 5.10 == -1.95e-06
  [3] 4.83 - 4.83 ==  7.15e-08
  [5] 5.17 - 5.17 == -4.82e-08
  
  ══ testthat results  ═══════════════════════════════════════════════════════════
  [ OK: 1005 | SKIPPED: 20 | WARNINGS: 0 | FAILED: 1 ]
  1. Failure: stan intervals (@test_linear_reg_stan.R#119) 
  
  Error: testthat unit tests failed

The perplexing part of this is that this test should not be run and is not on R-hub, travis, or winbuilder. rstanarm is not a dependency for parsnip and these test contain a skip_if_not_installed("rstanarm"). The only way that I could see these running is either:

• He modified the DESCRIPTION file (which he has done many times before) or wrote a special case for parsnip
• His library path used for testing contains packages not included in the DESCRIPTION file. This is discordant with how R CMD check is supposed to operate.

Either way, I'll change the tolerance for the test and add skip_on_cran() for this to ensure that their results are consistent and reproducible (unless there are more shenanigans).

If anyone reading this is wondering why I would have a test case for a package that is not installed... building the stan package adds a significant time to the build environment (travis often times out when these are added to the existing formal dependencies). We run these tests locally on a regular basis.

[topepo]

on cran now

[github-actions]

This issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with a reprex: https://reprex.tidyverse.org) and link to this issue.