Is such “transparent” testing framework a good idea? [on hold]

Here is an example in R, but the concept applies to any language that supports file IO. I’m presenting it in R just because its special operator overriding feature makes the syntax looks nicer.

`%<-verify%` <- function(x, new.value) {   name <- deparse(substitute(x))   save.file <- paste0(name, '.rds')    if (!file.exists(save.file)) {     message(paste('Generating', save.file))     saveRDS(new.value, save.file)     assign(name, new.value, inherits=TRUE)   } else {     old.value <- readRDS(save.file)     if (!isTRUE(delta <- all.equal(old.value, new.value))) {       warning(delta)     } else {       message('checked')     }     assign(name, old.value, inherits=TRUE)   } } 

Let me explain it in action. Say you just receive a legacy codebase and want to clean that mess up.

> get.answer <- function() bitwXor(0xDEAD, 0xBEEF) %% 100 

First, you need to run some examples, so that the test framework can learn what the result should be. When a name is assigned with %<-verify% for the first time, its value is stored to a file (named after it to prevent namespace collisions).

> source('test-util.R') > answer %<-verify% get.answer() Generating answer.rds > answer [1] 42 

All subsequent %<-verify% to this name automatically checks the new value against the saved value, and emit a warning if they don’t agree.

> get.answer <- function() 43 > answer %<-verify% get.answer() Warning message: In answer %<-verify% get.answer() : Mean relative difference: 0.02380952 

Effectively, this prevents the codebase from being broken by the new changes.

> get.answer <- function() 42 > answer %<-verify% get.answer() checked 

Note that you should only use %<-verify% on the interfaces you care about, for example, the exported functions. If you i %<-verify% i + 1 within a loop then be prepared for a wall of warnings.

Its main merit is transparency, that you can just replace <- with %<-% and the check is done automatically. People are lazy, so making tests easier to implement basically creates more tests, and errors can be detected at an earlier stage.

Do you think this is a good practice?