If you have ever tried to create your own package in R, you have probably also experienced the urge to throw your laptop across the room. Whether it's a Git issue, a mistyped line of code that messes up your variables, or some error that even the depths of Google cannot tell you what it means, we have all been there. This past week, the class worked to set up practice packages and I think a new error came up with every step. I can only imagine the pain if I had been writing the code from scratch. I think the only thing that saved my sanity was my marketing class getting cancelled so the professor could take us to Old Mill for ice cream (and of course the adorable Binksley).

The struggles of the past week and the ones I know are fast approaching are why I chose to read “Designing Your Test Suite”, which is chapter 14 in the book, R Packages 2nd Edition, by Hadley Wickham and Jennifer Bryan. The chapter explained how to set up tests, what to test, and how to make them as efficient as possible. There were quite a few times in my work that I did not realize something had failed until like three steps later. If I had been using a testing function, these failures would be identified immediately, not ten minutes later.

In her newsletter, “The Total Package”, Sara discusses how important the explore, refine, produce framework is in preserving data integrity. After reading this, I immediately remembered our Karen Training assignment and all of the merge and variable issues we faced when trying to find the proportions of something (Don’t even get me started on using “count”). I had to clear my environment and rerun code countless times. One of the things I found most interesting in the chapter I read was that each “test_that()” function had its own environment, as is shown in the image below.

If I had tried to test my merges and variable creations before implementing them into the global environment, I could have saved myself from quite the headache. There would have been less overwrites of variables and about 100 fewer “rm(list = ls())” commands typed in my console.

As we continue to progress in the class and start working with our clients, I know preserving the integrity of the data will be extremely important. If a merge error occurs and a variable is duplicated, we may not notice until later down the line when trying to advise our client. By utilizing test functions, we can confirm that the data is being merged properly before it is too late. This makes the Explore, Refine, Produce Framework more reproducible because we will have documentation and can check each step as it happens instead of simply hoping everything works.

Until next week,

Aylee and Binksley