3 ms·
I think it always makes sense to have an oracle, or a few. Nothing super fancy, just a few values you _know_ have a certain outcome. f(4,5) == 6 is good en
by jfoutz 5y ago
I think it always makes sense to have an oracle, or a few. Nothing super fancy, just a few values you _know_ have a certain outcome.
f(4,5) == 6
is good enough. just, whatever you type in to test as you develop the code, write it down and save it for later.
I mean, yeah, you can go nuts with boilerplate. But, I always seem to regret not having written down a handful of cases. If nothing else, it helps me remember what the heck this function is for, and a few samples of expected input and output, along with source are more immediately useful (to me) than comments.
Opinions differ. This isn't a hill I'll die on - as evidenced by my lack of tests from time to time. But I've never regretted the few minutes to provide them, and I have regretted not providing them
- epistasis 5y agoThat sort of test doesn't really apply here in any meaningful way. Suppose you want to validate that a certain column is in the file. You could place your assumptions around that explicitly in the read_tsv function call and have it generate the error for you on reading the file, or it can generate an error when you try to use that column. Either way, there's no "test" yet the intention is clearly stated in the code, and the code will simply fail out rather than proceed if it encounters input that can't be meaningfully used. This code is in many ways a declarative use of other code, describing the data, doing some joins and filtering, and plugging it into well tested libraries of code. The data structures that store the data and the library functions that deal with the data are designed in a way that bugs often result in errors immediately. In many ways it's like writing a SQL statement. One could make test data tables and make sure that the SQL statement does what one expects, but the SQL statement already embodies intent in the same way that a test of code would embody intent.
- jfoutz 5y agoSo, I'm not an R guy, but I pawed through some of the code. I get what you're saying, there's an environment, it needs to be just so, or it won't work. that's fine. And yeah, it does feel a lot like SQL. I would point out this guy - https://github.com/TheEconomist/covid-19-the-economist-global-excess-deaths-model/blob/025cb1921500fa43da5ea56a877b1069833b7824/scripts/1_excess_deaths_global_estimates_script.R#L714 https://github.com/TheEconomist/covid-19-the-economist-globa... that sort of has the look of something that took a pass or two to get right. And I think, would be nice to have a test case (sample call). Again, not a hill I'm going to die on. Overall, I don't think we have a big difference of opinion, yeah, it looks like gluing together libraries - as a non, native R speaker, I think I can make sense of the project, it's cool they put it out there, and I don't think there's anything _wrong_ with what they've got.
- nojito 5y agoThat function is pretty standard. If you want to run a loess, it runs the loess function if not it runs a windowed average. What exactly would you test it for?
- epistasis 5y agoThis is actually one case where I could see jfoutz's point! If I were developing this, I'd probably be running it in a notebook, and inspecting output on a few rows from the data frame. It would be easy enough to capture both the input and output and throw it into a stopifnot to record the testing that was performed interactively.