Actually, Marianne, our approaches aren't too different (I also live in the tidyverse). I also use testthat for unit testing of minor issues in my analysis. However, this is about defensive programming (hence the subject topic), which is done using the assertive and assertr packages, not testthat. I agree that unit testing would be useful to include, but not defensive programming. As I mentioned, defensive programming is a bit unwieldy (see the vignette for assertive for an example).
The other thing to keep in mind is that unit testing is done under the framework of an R package development flow (generally; testthat is tightly integrated with devtools). So that would require that we also include some mention of R package development via the devtools. End of the day, are we talking about unit testing or defensive programming? They are very different. Luke On 2016-09-30 03:32 PM, Marianne Corvellec wrote: > Hello, > > My approach is quite opposite to Luke's. > > I mostly do exploratory "data analysis at an individual > researcher/team level" precisely. I use knitr/R Markdown dynamic > reports (think Jupyter notebooks, for all the Pythonistas out there). > > At this (exploratory) stage, I don't do testing per se. But I *need* > to have some sanity checks along the way! So I have a few > `expect_true()`, `expect_that()`, etc. (from the `testthat` package) > here and there. It's not testing, it doesn't really cover much, but I > need to be a little defensive so that I can trust what's being > computed... > > I know that `testthat` is intended for unit testing but, you know, I > live in the Hadleyverse. :) > > Cheers, > Marianne > > On Fri, Sep 30, 2016 at 1:50 PM, Luke Johnston <[email protected]> wrote: >> I agree with Naupaka that it is a bit advanced. However, the package >> `testthat` is not for defensive programming per se, but for unit tests. For >> defensive programming specifically there is the `assertive` and `assertr` >> packages. However, unlike Python, the facilities for defensive programming >> are not as well developed in R and are a bit unwieldy. Considering >> programming is not often done in R for a larger user base but rather for >> data analysis at a individual researcher/team level, I don't think it is >> worthwhile to add too much/anything to the defensive programming for R. The >> lessons are packed enough as it is. >> >> In addition to that, most people coming to the R workshops are looking to >> learn about data and statistical analysis. Defensive programming is >> something they would likely never use. I've used R for several years and >> develop a few packages and even I very rarely use these defensive >> facilities. >> >> Just my two cents. >> >> Luke >> >> >> On 2016-09-30 12:52 PM, Naupaka Zimmerman wrote: >> >> Hi Raniere - >> >> I think it isn't a part of the materials because it's a bit advanced for the >> usual audience level. But that's not to say it wouldn't be nice to have. I >> imagine such a lesson could intro the base assertion functions like >> stopifnot() and also Hadley's testthat package. PRs welcome! >> >> Best, >> Naupaka >> >> On 30 Sep 2016, at 8:19, Raniere Silva wrote: >> >> Hi all, >> on our Programming with Python, >> http://swcarpentry.github.io/python-novice-inflammation/08-defensive/, >> we have a "Defensive Programming" section. >> This section is missing on the R lesson. >> Any experience R instructor can let me know why? >> And if you have your "translation" of that lesson in R >> could you send me a copy of it? >> Cheers, >> Raniere >> _______________________________________________ >> Discuss mailing list >> [email protected] >> >> http://lists.software-carpentry.org/listinfo/discuss >> >> >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> http://lists.software-carpentry.org/listinfo/discuss >> >> >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> http://lists.software-carpentry.org/listinfo/discuss _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
