testthat 3.3.0 #765
testthat 3.3.0 #765
Conversation
|
|
||
| Overall it was a successful experiment. It helped me close over 100 issues in what felt like less time than usual. I don't have any hard numbers, but my gut feeling is that it was maybe a 10-20% improvement to my development velocity. This is still significant, especially since I'm an experienced R programmer and my workflow has been pretty stable for the last few years. I mostly used Claude for smaller, well-defined tasks where I had a good sense of what was needed. I found it particularly useful for refactoring, where it was easy to say precisely what I wanted, but executing the changes required a bunch of fiddly edits across many files. | ||
|
|
||
| I also found it generally useful for getting over the "activation energy hump": there were a few issues that had been stagnating for years because they felt like they were going to be hard to do and with relatively limited payoff. I let Claude Code loose on a few of these and found it super useful. It only produced code I was really happy with a couple of times, but every time it gave me something to react to (often with strong negative feelings!) and that got me started actually engaging with the problem. |
There was a problem hiding this comment.
Anger-driven engagement algorithm for coders
|
|
||
| ## Other new features | ||
|
|
||
| * testthat generally does a better job of handling nested tests, aka subtests, where you put a `test_that()` inside another `test_that()`, or more typically `it()` inside of `describe()`. Subtests will now generate more informative failure messages, free from duplication, with more informative skips if any subtests don't contain any expectations. |
There was a problem hiding this comment.
I thought nesting test_that() was mostly useful for testing the testthat package with itself, but this paragraph makes it sound like there might be user-oriented cases where this is helpful? If that's the case, it might be interesting to add a sentence explaining the use case, otherwise a sentence explaining this is mostly for internal testing.
There was a problem hiding this comment.
It's mostly about making it possible to write tests inside of functions that get called inside of other tests. This is sometimes useful when you want to test that multiple functions/classes adhere to the same interface. But I'm also not 100% convinced that it's the right approach, so I don't want to go into the details here.
|
|
||
| * `vignette("mocking")` explains mocking in detail, and new `local_mocked_s3_method()`, `local_mocked_s4_method()`, and `local_mocked_r6_class()` make it easier to mock S3 and S4 methods and R6 classes. | ||
|
|
||
| * `test_dir()`, `test_check()`, and friends gain a `shuffle` argument that uses `sample()` to randomly reorder the top-level expressions in each test file. This random reordering surfaces dependencies between tests and code outside of any test, as well as dependencies between tests, helping you find and eliminate unintentional dependencies. |
|
|
||
| * `test_dir()`, `test_check()`, and friends gain a `shuffle` argument that uses `sample()` to randomly reorder the top-level expressions in each test file. This random reordering surfaces dependencies between tests and code outside of any test, as well as dependencies between tests, helping you find and eliminate unintentional dependencies. | ||
|
|
||
| * `try_again()` is now publicized, as it's a useful tool for testing flaky code: |
There was a problem hiding this comment.
Interesting, might be worth a note that this should still be skipped on CRAN? And include a skip_on_cran() in the example.
| * New `SlowReporter` makes it easier to find the slowest tests in your package. You can run it with `devtools::test(reporter = "slow")`. | ||
|
|
||
| * New `vignette("challenging-functions")` provides an index to other documentation organized by various challenges. | ||
|
|
There was a problem hiding this comment.
To use the new features, do you recommend bumping the version of testthat in Suggests? Might be a good place to mention it.
Unfortunately pkgload only checks for Imports not Suggests, so bumping the dep won't trigger the install prompt on load.
There was a problem hiding this comment.
Yeah, and install.packages() won't check for it either. So overall, I don't think it's worth it.
teunbrand
left a comment
teunbrand
left a comment
There was a problem hiding this comment.
It makes me excited to try out the new features!
|
So many cool changes! Sidenote: My local preview, opened in Firefox, has the horizontal line in the test_that() output piercing out to the right. |
|
@hfrick thanks for spotting. fixed now! |
First draft