softloud / neet

Coding to code::proof: Boundary checks for test-driven development.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Travis build status

thoughts on using it so far

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.

neet:: Test for non-empty thing of expected type

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.

Installation

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")

Example

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

Workflow

The neet:: package supports a coding workflow.

workflow(0)

This section describes the test-driven workflow presented above as a code::proofed 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:

  1. code::registration
  2. tests
  3. code

coding to code::proof workflow

The tests vary each time in complexity, so that the complete model cycle consists of ten phases of work:

  1. code::registration
workflow(1)

In an issue on GitHub:

  1. Describe the algorithm’s intended purpose.
  2. Describe the input parameters and how they will be tested.
  3. Describe the output parameters and how they will be tested.

purpose

A duck that "quack"s.

input

Nothing.

output

  • one neet
  • all neets
  • and the rest

Character string “quack”.

  1. 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"
  1. 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"
  1. 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
  1. 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))
})
  1. code

The duck quacks sufficiently. No more code required!

  1. code::registration
workflow(7)

Either update or rewrite the code::registration.

  • one neet
  • all neets
  • and the rest
  1. tests, and the rest, i.e., any other cases to test for

I am satisified with the test coverage.

  1. code

The duck quacks sufficiently.

  1. 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.

About

Coding to code::proof: Boundary checks for test-driven development.

License:Other


Languages

Language:R 100.0%