question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Writing unopinionated tests cases

See original GitHub issue

Something 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:open
  • Created 2 years ago
  • Comments:18

github_iconTop GitHub Comments

1reaction
jimmywartingcommented, Sep 1, 2021

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

1reaction
CMEONEcommented, Jul 14, 2021

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Developers - Writing unopinionated tests cases - - Bountysource
Writing unopinionated tests cases. ... I have begun to do in my own projects is writing test without any testing framework like mock,...
Read more >
Writing Layout Tests
Each test case describes the circumstance that it tests, without being redundant. Do not start test case descriptions with redundant terms like “Testing”...
Read more >
How to Write Test Cases: The Ultimate Guide with Examples
This in-depth hands-on tutorial on How to Write Test Cases covers the details of what a Test Case is along with its standard...
Read more >
Automation Testing: What You Should Know | Bits and Pieces
The bigger the return on investment is, the more automated test cases you ... Instead of writing tests, automation testers spend their time...
Read more >
How To Automate Your Tests? A Detailed Guide - Preflight
This establishes the fact that only unopinionated tests can be automated. ... Test automation frameworks can surely execute the created test cases with...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found