Still not convinced of the utlity of this code. Perhaps better simply to
write an expect success as a neet. Trying it out, however, has been very
useful for adopting some level of test-driven
development.
One particular drawback of this code is that it messes up the error line
when reporting, and that’s a massive drag when debugging. However, I
learnt a lot from building it.
A neet test tests for non-empty thing of expected type. This is what is referred to as a boundary condition test in RStudio’s primers (todo: citation).
These expectations are intended to integrate into minimal testing workflow for development of data analyses. When developing a function, we will need parameters, and structure of the pipeline. These tests enable the developer to feel reassured the pipeline’s functions are outputting non-empty thing of expected type, while the developer decides the best structure for an analysis pipeline.
A character
string will be checked for being of string-length > 1.
A numeric
is checked for not being NA
, NULL
, Inf
, or -Inf
.
A `list`` is checked for being of length > 1.
A data.frame
is checked for having at least one row.
You can install the released version of neet
from GitHub with:
# install devtools
install.packages(devtools)
# use devtools to install package from github
devtools::install_github("softloud/neet")
library(testthat)
library(neet)
## basic example code
# assertions check inputs of code in function scripts
assert_neet(3, "numeric") # test numeric
#> [1] TRUE
assert_neet("cat", "character") # test character string
#> [1] TRUE
assert_neet(mtcars, "data.frame") # test data frame
#> [1] TRUE
# tests to check neet expectations in testthat files
test_neet(3, "numeric") # test numeric
test_neet("cat", "character") # test character string
test_neet(mtcars, "data.frame") # test data frame
The neet::
package supports a coding workflow.
workflow(0)
This section describes the test-driven workflow presented above as a
code::proof
ed coding to doneness.
The model workflow comprises three stages, repeated three times, before
returning to the start, the code::registration
. We use model to
suggest the workflow may be adapted for different use-cases.
Each phase consists of:
code::registration
- tests
- code
The tests vary each time in complexity, so that the complete model cycle consists of ten phases of work:
code::registration
workflow(1)
In an issue on GitHub:
- Describe the algorithm’s intended purpose.
- Describe the input parameters and how they will be tested.
- Describe the output parameters and how they will be tested.
A duck
that "quack"
s.
Nothing.
- one neet
- all neets
- and the rest
Character string “quack”.
neet
tests, one per function
workflow(2)
Write a test to check the duck quacks at all. This test currently fails, because I have not written the code to make it pass, yet.
test_that(expect_match(duck(), "quack"))
#> Error in duck(): could not find function "duck"
- code
workflow(3)
Write code to make the test pass.
# write function
duck <- function() {"quack!"}
And now no error message is returned.
test_that(expect_match(duck(), "quack"))
#> Error in duck(): could not find function "duck"
code::registration
Either update or rewrite the code::registration
. It becomes more
obvious what code needs to be written once the developer has spent some
time again with the function.
- one neet
- all neets
- and the rest
neet
tests, for all inputs for each function
workflow(5)
Now consider all inputs. Since we have nothing, we might consider the case where there is something, and write a test that expects an error.
test_that("function fails with input", {
expect_error(duck(3))
})
- code
The duck quacks sufficiently. No more code required!
code::registration
workflow(7)
Either update or rewrite the code::registration
.
- one neet
- all neets
- and the rest
- tests, and the rest, i.e., any other cases to test for
I am satisified with the test coverage.
- code
The duck quacks sufficiently.
code::registration
workflow(10)
- one neet
- all neets
- and the rest
For the final code::registration
, update the document for your future
self with details you may need when implementing new features.