Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/markvanderloo/tinytest below:

markvanderloo/tinytest: A lightweight, no-dependency, but full-featured package for unit testing in R

A lightweight, no-dependency, full-featured package for unit testing

Overview of functionality, or Watch my talk at useR!2021

In R, do

install.packages("tinytest")

In your (bash) shell, do

git clone https://github.com/markvanderloo/tinytest
cd tinytest
make install

Testing infrastructure must not get in the way of the developer. Setting up tests should be done with ease. In tinytest tests are simple R-scripts where test statements can be interspersed with other code (e.g. to prepare some results for testing).

The purpose of testing is to gather evidence (data) that builds confidence in the quality of software. Unit tests consist of expressions where an expected result is compared with the result of a program or function. For example:

addOne <- function(x) x + 1
subOne <- function(x) x - 2

# this test should pass
tinytest::expect_equal(addOne(1), 2 )

# this test will fail
tinytest::expect_equal(subOne(2), 1 ) 

Some unit testing frameworks for R throw a formal exception (error) whenever a test fails. There are several reasons why this is not a good idea.

1. You do not need to throw an error to discover that a test has failed. A boolean result is in principle enough.
2. A traceback of the error does not give you any information on the cause of the test failure. This is because the test function throws the error, not the tested code.
3. Throwing errors complicates the code needed for developing a testing suite, making testing suites harder to maintain and possibly more complex to use than necessary.

tinytest therefore treats test results as data, not as exceptions. This data can be summarized and investigated by any method you already know in R.

There is a case where the failure of a test should cause an error, namely when testing for deployment (e.g. publishing a package on CRAN). Therefore, when running R CMD check, an error will be thrown if a test has failed. This way the error interrupts the deployment process instead of the testing process.

By default all tests are run and the results are summarized to one line of output per failed test.

So a package author can request test results from users that installed the package.

Developing and debugging takes focus and often deep concentration. tinytest supports your workflow by directing you as quickly as possible to the source of the test failure. In a single line of output you get the test result, the file and location in the file, and the test call that failed. Of course, printing is configurable through options.

Keep it simple, keep it clean. See tinyverse.org.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4