Skip to content

testthat 3e#1165

Open
VisruthSK wants to merge 33 commits intomasterfrom
testthat-3e
Open

testthat 3e#1165
VisruthSK wants to merge 33 commits intomasterfrom
testthat-3e

Conversation

@VisruthSK
Copy link
Copy Markdown
Member

@VisruthSK VisruthSK commented Mar 24, 2026

Migrated to latest testthat edition.

Closes #1155.

@jgabry
Copy link
Copy Markdown
Member

jgabry commented Mar 24, 2026

Thanks for working on this!

@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented Mar 24, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.87%. Comparing base (5809552) to head (f7868cc).
⚠️ Report is 7 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1165      +/-   ##
==========================================
+ Coverage   90.85%   90.87%   +0.02%     
==========================================
  Files          14       15       +1     
  Lines        5924     5938      +14     
==========================================
+ Hits         5382     5396      +14     
  Misses        542      542              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@VisruthSK
Copy link
Copy Markdown
Member Author

@jgabry do you know why macos devel would be failing in the R dep setup? Doesn't seem to happen in main--could this be a cache/GHA error? https://github.com/stan-dev/cmdstanr/actions/runs/23573417706/job/68640740296

@VisruthSK VisruthSK marked this pull request as ready for review March 26, 2026 16:14
@VisruthSK
Copy link
Copy Markdown
Member Author

Looks like something is broken in R Core or pak which is causing macos devel to fail.

@VisruthSK VisruthSK requested a review from jgabry March 26, 2026 22:16
@jgabry
Copy link
Copy Markdown
Member

jgabry commented Mar 26, 2026

Looks like something is broken in R Core or pak which is causing macos devel to fail.

Took a quick glance at the logs, I agree this seems likely. I’ll try to take a look at the actual PR tomorrow.

@VisruthSK
Copy link
Copy Markdown
Member Author

VisruthSK commented Mar 26, 2026

Thanks! Looks like this (new) function in tools is broken, planning on submit a patch.

Got fixed, so should be gtg soon

Copy link
Copy Markdown
Member

@jgabry jgabry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly looks great, just a few comments/questions.

@jgabry
Copy link
Copy Markdown
Member

jgabry commented Mar 30, 2026

Got fixed, so should be gtg soon

Still seems broken (hitting the same error in other repos too)

@VisruthSK
Copy link
Copy Markdown
Member Author

I see builds failing, but I think the specific error that I ran into should be fixed. I think the C API changed so some packages aren't building (abind in posterior, lazyeval in bayesplot). I don't think there are any other deps which are problematic on devel for cmdstanr, so hopefully this run will go through

@jgabry
Copy link
Copy Markdown
Member

jgabry commented Mar 30, 2026

I see builds failing, but I think the specific error that I ran into should be fixed. I think the C API changed so some packages aren't building (abind in posterior, lazyeval in bayesplot). I don't think there are any other deps which are problematic on devel for cmdstanr, so hopefully this run will go through

It's still failing in other recent cmdstanr PRs. This one is from today:

https://github.com/stan-dev/cmdstanr/actions/runs/23760099930/job/69225022781?pr=1166

Not a big deal, we can just wait for it to sort itself out I guess?

@VisruthSK
Copy link
Copy Markdown
Member Author

Missed that. Not sure why its still failing since the code is fixed in source--maybe the R install is cached? Waiting it out seems good to me.

@VisruthSK VisruthSK marked this pull request as draft March 31, 2026 19:30
@VisruthSK
Copy link
Copy Markdown
Member Author

There are still some snapshots since expect_known_output() was deprecated and the suggestion is to use a snapshot.

@VisruthSK VisruthSK marked this pull request as ready for review April 1, 2026 01:03
expect_not_true <- function(...) expect_false(isTRUE(...))

transform_print_snapshot <- function(x) {
vapply(x, function(line) {
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These aren't needed for this PR, but left them in for the snapshot PR as they're helpful in normalizing results.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to put them in this PR as opposed to the snapshot PR where they'll actually be used? I guess I can look at them as part of this PR, but I would kind of prefer to review them as part of the PR where they are used, so I can see them in use when reviewing them.

@VisruthSK
Copy link
Copy Markdown
Member Author

I swapped a number of things to use withr functions instead of base R so that tests don't have to manually clean up after themselves with a bunch of on.exit() calls. withr is already a suggested import so I see no reason not to swap.

@VisruthSK VisruthSK requested a review from jgabry April 1, 2026 14:52
Copy link
Copy Markdown
Member

@jgabry jgabry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good. Just a couple of comments/questions/suggestions. Might have more, but maybe not.


# would error if fitting failed
expect_silent(fit$draws())
expect_no_error(fit$draws())
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think testthat 3e still supports expect_silent() right? Any reason to weaken this test to expect_no_error()?

fail(sprint("Model executable '%s' does not exist after compilation.", mod$exe_file()))
}
if(!is.null(before_mtime)) {
if(!is.null(before_mtime) && mtime_check_enabled) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the motivation for adding the new mtime_check_enabled?

Comment on lines +1 to +9
local({
stan_files <- dir(test_path("resources", "stan"), pattern = "\\.stan$", full.names = TRUE)
exe_files <- cmdstanr:::cmdstan_ext(cmdstanr:::strip_ext(stan_files))
existing_exe_files <- exe_files[file.exists(exe_files)]
if (length(existing_exe_files) > 0) {
unlink(existing_exe_files, force = TRUE)
}
})

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems useful, but was this added because we weren't starting from a clean slate before or just as an extra precaution?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, we already have teardown-remove-files.R, which does something similar that runs after the tests.

I think maybe the best approach is to replace both the new code here and the teardown file with a single setup file that does both jobs in one place? I think both instead of one or the other because the pre-run cleanup is sufficient but the post-run teardown is nice especially if running tests locally.

What do you think?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we could have a function defined in setup.R that cleans up the files and then call it twice in setup, deferring the second one? Something like this maybe:

cleanup_stan_exes()
withr::defer(cleanup_stan_exes(), testthat::teardown_env())

json_output_df <- readLines(temp_file_mat)
expect_identical(json_output_df, json_output_mat)
expect_identical(readLines(temp_file_df), readLines(temp_file_mat))
announce_snapshot_file(name = "json-df-matrix.json")
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious why this is needed?

expect_not_true <- function(...) expect_false(isTRUE(...))

transform_print_snapshot <- function(x) {
vapply(x, function(line) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to put them in this PR as opposed to the snapshot PR where they'll actually be used? I guess I can look at them as part of this PR, but I would kind of prefer to review them as part of the PR where they are used, so I can see them in use when reviewing them.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Swap to testthat 3e

3 participants