Set up Travis CI

[btskinner]

We don't have much to test at the moment, but I want to get the .travis.yml set up. The idea will be to unit test all functions.

NOTES

• small utility functions are easy since we can test them without data
• functions to run analyses (e.g., {tidymodels} functions) will need fake data or a small subset of the ELS data since we don't want to push large files or require long Travis checks

[ozanj]

I don't know what Travis CI is or .travis.yml

I don't know what you mean by unit test all functions

what package do you use to create fake data?

would you consider playing with the package fabricatr which is part of the DeclareDesign package developed by my poli sci prof in the experimental design class Patricia and I are taking this quarter? also, we are considering using fabricatr and declaredesign for the research project we owe deliverables on

[btskinner]

@ozanj: Travis CI is a really cool (and free for us) utility that will perform tests for us any time we push to the repo. Typically, people use tests when building software packages. For example, I have Travis CI set up for my {rscorecard} package to make sure that it builds and that the unit tests I set up pass.

Unit tests are just tests that make sure a function is doing what we think it is doing using the smallest possible tests of expected behavior as well as tests of edge cases and expected errors. For example, if you have a function:

## unnecessary function to calculate x to the z power
my_exp <- function(x, power) { 
    out <- prod(rep(x, power))
    return(out)
}

You want to make sure that you get the results you expect:

## expect 2
my_exp(2, 1)

## expect 4
my_exp(2, 2)

## expect error since we don't account for negative exponents
my_exp(2, -1)

If we don't get what we expect, then we are suspicious that our functions aren't performing the way we expect, even if they "work." Unit tests through R's {testthat} package will let us formalize this process, and Travis CI will automatically run these tests whenever we push to the repo. This way, we don't break something old when we add something new.

I will set this up and it won't change anything about the way we work with GitHub other than to warn us about possible problems.

I will look into the {fabricatr} package. It seems like just what we need.

[ozanj]

thank you Ben!

this explanation was super helpful. I am learning stuff already!

[btskinner]

This has been added the #22 PR. If we decide not to integrate that PR, I can pull it out and merge from a different branch.