Switching away from AVA and simplifying testing

[dmitriz]

Some of the features of this package have been its quality and minimalism. Right now, ava and tape test runners are included in the dev dependencies, which means anyone cloning the repo gets these packages downloaded with any npm install command. However, these runners do not really belong to the library and one might not need them and want to install them locally.

A simple workaround is to run scripts via npx, which is sadly not possible with ava and tape, since they import locally installed modules with the same names. On the other hand, jest seems to be very popular these days and not to have this problem. Thus, switching to jest or any tester with similar features would free up this repository from any hard-coded dependency, including dev dependencies. It will be possible to run the tests via npx on the need-to-do basis.

There are also some hacks currently used with running ava, such as avoiding declaring it in the tests, to make those look more universal like this:

const test = require('./config')
const { pipe } = require('..')
test('pass single argument to single function', t => {
	t.is(pipe(x => x + 2)(1), 3)
})

As such, our tests here already look portable to other runners using the test function, such as jest. Except, one does not need to import it as module in jest, so fewer LOC in each test function. I get the motivation from AVA to avoid using globals, which is generally a good principle. However, in this case, globals would only be used for testing of this minimal code, where a small set of globals should be easy to deal with, and based on jest's popularity, I presume that hasn't been perceived as major issue even in much larger projects. On the other had, the benefit of writing fewer LOC reducing the noise feels to have its merit.

On a possible downside of such change, the standard jest syntax would feel more verbose:

	t.is(pipe(x => x + 2)(1), 3)
//vs
       expect(pipe(x => x + 2)(1)).toBe(3)

On the other hand, the second line above can be potentially automatically generated from the first one with a simple patching like this:

t.is = (a,b) => expect(a).toBe(b)

Thus, it seems potentially possible to migrate to jest with minimal changes keeping all tests as they are, followed by removing the (noisy) module loading and explicit package installation.

Will be curious to hear anyone's thoughts or ideas on the subject.