The three components of a software package are equally important in my eyes: source code, documentation, and tests. Usually I start working on the source code like most other developers, and I’ll finish the R package documentation at the same time. The package documentation is often too dry and not enough for users to learn a package systematically, because the topics in the package documentation are not arranged in a logical manner (only listed alphabetically). So I have also been trying to write books. These things have consumed me a considerable amount of time, so I have been leaving tests behind, even though I hate doing so.
Now I have identifed three packages that seriously lack testing (I have also opened GitHub issues for them):
I hope someone could help me with them. Personally I use a tiny package named testit for testing: https://github.com/yihui/testit (I guess most other people use testthat but I don’t find its sophistication appealing to me). If you use RStudio, you may run the tests via Ctrl / Cmd + Shift + T, which essentially runs R scripts under the tests/ directory.
A test with testit is typically in this format:
library(testit)
assert('What a function is expected to do', {
(FUN(args, ...)) %==% EXPECTED_OUTPUT)
})
For example:
assert('as.character() converts values to character', {
(as.character(123) %==% '123')
(as.character(1:3) %==% c('1', '2', '3'))
})
Note that:
-
You can write multiple expressions inside the curly braces
{ }. If an expression is inside a pair of parentheses(), it is expected to return a logical vector ofTRUE’s (cannot be of length zero or containNA), otherwiseassert()will signal an error to indicate the test failure. Expressions not in()are evaluated as normal R code and their values are not checked. -
The infix operator
%==%is a shorthand ofidentical(), i.e.,x %==% yis the same asidentical(x, y). You might use==for less strict comparisons, e.g.,1:3 == c(1, 2, 3)will beTRUE(of length 3), but1:3 %==% c(1, 2, 3)isFALSE(because integer is not identical to double).
Of course, many of other packages that I maintain also lack sufficient testing (e.g., knitr). Please feel free to work on any packages you like. I believe as you work on these tests, you will understand many internal functions much better, because you have to clearly know what each function is supposed to do! Sometimes you may have to split a big function into smaller ones, and test these small parts separately. Please feel free to refactor/split whenever you think is necessary. I’ll be waiting for your pull requests! Thanks!

Donate
As a freelancer (currently working as a contractor) and a dad of three kids, I truly appreciate your donation to support my writing and open-source software development! Your contribution helps me cope with financial uncertainty better, so I can spend more time on producing high-quality content and software. You can make a donation through methods below.
-
Venmo:
@yihui_xie, or Zelle:xie@yihui.name -
Paypal
-
If you have a Paypal account, you can follow the link https://paypal.me/YihuiXie or find me on Paypal via my email
xie@yihui.name. Please choose the payment type as “Family and Friends” (instead of “Goods and Services”) to avoid extra fees. -
If you don’t have Paypal, you may donate through this link via your debit or credit card. Paypal will charge a fee on my side.
-
-
Other ways:
WeChat Pay (微信支付:谢益辉) Alipay (支付宝:谢益辉) 

When sending money, please be sure to add a note “gift” or “donation” if possible, so it won’t be treated as my taxable income but a genuine gift. Needless to say, donation is completely voluntary and I appreciate any amount you can give.
Please feel free to email me if you prefer a different way to give. Thank you very much!
I’ll give back a significant portion of the donations to the open-source community and charities. For the record, I received about $30,000 in total (before tax) in 2024-25, and gave back about $15,000 (after tax).