Writing unopinionated tests cases
See original GitHub issueSomething I have begun to do in my own projects is writing test without any testing framework like mock, tape, ava, airtap, etc
Why?
- I think they are simply too bloated, have many dependencies and takes a long time to install and be executed on CI.
- Every dependency is a potential security vulnerability.
- The tests are hard to execute on any environment.
<script>
,<script type="module">
, NodeJS, Deno, Web Worker, Service Worker, etc - The test cases are not so easily shareable with other libraries that builds forks that wish to run the same test cases.
i see now that NodeJS wishes to use our test cases in the core. Other libraries like undici-fetch also want’s to use our test
So how simple are my test cases?
as simple as importing a list of [{ desc, fn }]
where fn either returns a boolean and hooking them into console.assert
or require('assert')
…They could also return undefined or throw. I’m still experimenting with writing own tests from scratch
import tests, { override } from './test-cases.js'
import fetch from 'node-fetch'
override('fetch', fetch)
for (const { desc, fn } of tests) {
console.assert(await fn(), desc)
}
Cons:
Sure my test cases dose not have fancy tools like t.throws(fn, expected, msg)
or t.arrayEqual
or any like that
it only boils down to a booleans if it was ok or not. to compare a simple array of strings you can just sort them and call toString()
and check if a === b
or do arr1+"" === arr2+""
if it don’t need to be sorted and isn’t complex objects
it also don’t include any progress or output to terminal, console or the html view. This would be the job of hooking all the test cases into the test runner itself for (let test of cases) t.ok(t.desc, t.fn)
And you would have to be a little bit more explicit when you write the tests, like you would actually have to do the “expect to throw” logic yourself if you need anything like that
pros
- Lightning fast
- Unopinionated
- Can use any test framework you want and hook up all the unopinionated tests with a simple loop to eg tape
- Can re-run / re-use the test cases multiple times whenever you want.
- Don’t require 1000 of sub dependencies
Whenever i write code for anything then i have a onion architecture mindset when writing my code. This would mean:
- write test as they would not have any dependency on any core node modules or npm packages
- the implementation (aka fetch, header, response, etc) should be replaceable
- the test cases should easily be hooked into any test framework you want
This is how i wished WPT would work…
Want a taste of how i wrote test for my latest project that runs in Deno, NodeJS and browser without dependencies? …have a look at this: https://github.com/jimmywarting/native-file-system-adapter/tree/master/test
Issue Analytics
- State:
- Created 2 years ago
- Comments:18
Top GitHub Comments
I like Deno a lot. But I think it could be useful to have
Deno.test
as a seperate package so you can test your cross compatible code on both environment. (without importing the hole deno.ns)I write lots of code in cross compatible way so i don’t use much of node’s or deno’s builtin stuff unless i really need to. for instances i use Uint8Array instead of Buffer etc So i don’t necessary need the hole Deno namespace
Ok, what I will do is first port over the existing tests and feed them into mocha (but tests will be stored in the array format as you mentioned with the override capability). Then, I can start porting over the WPT tests into another test file or set of test files. I can keep the files separated as they are currently, with each testing file pointing to the corresponding array in a data file (imported into the testing file to actually apply the test cases), that way the data file can stay intact whenever we want to quickly swap out testing frameworks or use our own.