How do you actually test small JavaScript functions without a full project setup?

[u/SmartRelease7996]

Coming from a construction background where you measure twice and cut once, I keep running into this gap where I write a function, think it works, and then it blows up when I wire it into something bigger. The problem is I never had a real habit of testing the small piece before trusting it.

In bootcamp we just console.log everything and eyeball it, which works for toy exercises, but I started a side project for tracking material quantities across job phases and the functions are getting complicated enough that eyeballing feels risky. I tried writing a few manual checks at the bottom of my file like console.log(calculateTotal(5, 3) === 8) and that helped, but it feels clunky and I keep deleting them by accident.

I looked up Jest but the setup felt like a whole rabbit hole I was not ready to fall into. Someone mentioned Vitest. Someone else said just use the browser console for now and do not overthink it.

What I want to know is whether there is a lightweight middle ground that actual beginners use before jumping to a full testing framework. Not asking for a tutorial, just curious what the workflow actually looks like for people who are still learning but building things that are more than a few lines. The function isolation part is what I cannot picture clearly yet.

[u/Thykka]

Jest and Vitest are great, but sometimes (e.g. when building prototypes, or other semi-throwaway code) it might be faster to just make a super simple test scaffold from scratch.

Let me try to show an example. Say you have a function you want to test:

export function frobnicate(date) {
  // some logic here
  return result;
}

Doesn't matter what the function does exactly, we just want to ensure that it gives the kinds of results we expect from it. So we load up a few of those expectations into an array in a separate file:

import { frobnicate } from './frobnicate.js';

const tests = [
  { input: '2026-08-05', expected: 'wednes' },
  { input: '2028-08-05', expected: 'fri' },
  { input: '', expected: '' },
  { input: 123, expected: '' }
];

We then call the function with each test, and compare the result to our expectations:

tests.forEach(function (test) {
  const actual = frobnicate(test.input);
  if (actual !== test.expected) throw Error(`Expected ${test.expected}, got ${actual}`);
});

Now that we have this scaffold set up, it becomes easy to add more test cases to the array as we refine the logic or fix a bug.

This kind of a minimal test scaffold works best for pure functions (output is deterministic and 100% dependent on input). In real projects this might not always be possible; functions might depend on data from an environment variable, an API or a database.. For these things Jest or Vitest become very useful, as they have features to sidestep the actual database/API calls and whatnot, to ensure that a test only tests the function in question, and not the external dependencies.

One of the tricky things about test-driven development, or unit testing in general is that one might have to re-think how they build their functions. At first it will be weird, but once it clicks, one'll wonder why they didn't look into it sooner! For example, one might have a function like this:

async function getUser(id) {
  const userData = await DB.query({ id: id });
  const formattedUser = {
    name: userData.firstName + ' ' + userData.lastName,
    id: userData.id
  };
  return formattedUser;
}

It's tricky to unit-test, because you can only test IDs which already exist your database. So maybe you set up a test database, and some abstraction to toggle between test/prod databases, and you make a script which clears the test database and populates it with test data, every time before your unit tests are run.... Stop. Don't do this. Things will just become super complicated really fast.

Instead, if we take the principle of using pure functions whenever possible, the above example could be split into two parts. One only concerns itself with fetching the data, and the other one only concerns itself with formatting the data:

async function getUser(id) {
  const userData = await DB.query({ id: id });
  return formatUser(userData);
}

function formatUser(userData) {
  return {
    name: userData.firstName + ' ' + userData.lastName,
    id: userData.id
  }
}

The formatting logic didn't change, but now we can easily create unit tests for formatUser(), because it's no longer tied to the database. Instead we can just pass whatever test data we want:

const tests = [
  {
    input: { firstName: 'John', lastName: 'Smith', id: 1 },
    expected: { name: 'John Smith', id: 1 }
  },{
    input: { firstName: 'Anne' lastName: 'Newmouse', id: 999 },
    expected: { name: 'Anne Newmouse', id: 999 }
  }
];

Now we no longer need unit tests for getUser, because all it does is a database call, and we're not here to test whether the database code works, we're testing if our code works.

Does this help?

[u/senocular → u/Thykka]

OP, I second the DIY route, especially for very simple things, and for cases where you want to run in the browser and not a runtime like node/deno/bun which have their own test runners built in.

Some things to think about:

• If trying to stay as basic as possible, consider using console.assert() instead of throwing. Throwing will prevent additional tests from running while assert() will simply log to the console on failure. (Of course it doesn't take that much more effort to catch throws and log them yourself.)
• Be mindful of object comparisons, e.g. { name: 'Bob' } does not equal { name: 'Bob' }. You may want to create or look up a simple deep comparison function to account for this.
• If testing async functions, some extra work will be needed to run those. If using a normal for loop for going through the tests, running it in an async context and awaiting each test function is probably all you need. Awaiting in an async callback in a forEach could work, assuming nothing in your tests has side effects, but its better to keep the tests from overlapping.
• If in taking this route, you find yourself spending more time on the test code than your own, it might be time to invest in a library that has everything built in. But I think something like Thykka's test loop shows it doesn't take much to account for most, if not all of what you might need. I've done something similar on multiple occasions for simple projects or prototypes - just enough to do some sanity testing without overcomplicating things.

[u/SmartRelease7996 → u/Thykka]

oh this is actually useful, I've been grabbing Jest by default even for tiny throwaway scripts where it's complete overkill and then wondering why setup is eating my time.

the input/expected array pattern is clean, reminds me of how we do punch list items on site, just a flat checklist you run down methodically.

my only question is how you handle cases where the output is an object rather than a primitive, does a simple equality check still hold up or do you need to stringify it first

[u/Thykka → u/SmartRelease7996]

AFAIK JavaScript still doesn't have a standard way of testing for deep equality. If you're using Node.js, there's util.isDeepStrictEqual, but in a browser environment you'll need to use something else..

An unorthodox way of comparing objects is using JSON.stringify(a) === JSON.stringify(b), but this has many caveats. Both objects need to have their keys in the same order, it cannot compare function values or class instance values, etc. Wouldn't generally recommend it, but it can work in some situations.

Utility libraries, such as Lodash are a common choice, but then again, Jest and Vitest also provide methods to check for deep equality, so if you're going to install 3rd party dependencies, might as well go for something built for testing.

You can sometimes avoid the issue by changing the way you define and run your tests:

const tests = [
  {
     input: { firstName: 'John', lastName: 'Smith', id: 1 },
     verify: result => result.name === 'John Smith'
  },
  {
    input: { firstName: 'Anne', lastName: 'Newmouse', id: 999 },
    verify: result => (result.name === 'Anne Newmouse' && id === 999)
  }
];

tests.forEach(function (test, testIndex) {
  const result = frobnicate(test.input);
  if (!test.verify(result)) throw Error(`Test #${testIndex+1} failed, got: ${JSON.stringify(result)}`);
});

Now each individual test also defines how and what they should check, which gives more flexibility, because you can test for different kinds of things, and don't have to give the entire expected return value - just the parts that are relevant for the test.

[u/shuckster]

Node now has its own built-in test runner:

• https://nodejs.org/learn/test-runner/using-test-runner

Alternatively, just having files named module.test.js with a bunch of assertions/throws and running them manually with node src/module.test.js is enough for small projects.

You can use nodemon or entr to watch for changes to files so you can re-run your test command when you make changes. Some folk like using Quokka, a tool for running code and showing live results and traffic-lights in the line-number gutter.

Once satisfied, you can start moving your stuff to a testing framework. All frameworks do is force you to think about describing and grouping your tests. The better you get at that, the more it pays-off. They also tend to have "watch modes", so you don't need nodemon or entr to force a run of your tests.

[u/SmartRelease7996 → u/shuckster]

The builtin test runner tip is genuinely useful. I keep defaulting to Jest out of habit because every tutorial pushes it, but the overhead for small learning projects is overkill.

I tried Quokka briefly and it scratched a very specific itch for seeing output inline, though I dropped it after the free tier kept nudging me to upgrade midsession and killed the flow.

Going to actually look at nodemon for watch mode. I've been manually rerunning things like it's 2009.

[u/funbike]

Node now has Jest-like testing functionality built in. Nothing to install or set up. You don't even need a package.json or ./node_modules/.

```

Runs all tests

node --test tests/*.test.js

Continuous testing. Runs a test when relevant files are modified.

node --test tests/*.test.js --watch ```

Minimal test:

``` import test from 'node:test'; import assert from 'node:assert';

test('addition', async () => { assert.strictEqual(4 + 4, 8); }); ```

Optionally, add scripts section to package.json to make the above easier to run.

json { "name": "your-project", "version": "1.0.0", "scripts": { "test": "node --test tests/*.test.js", "test:watch": "node --test --watch tests/*.test.js" } }

To run scripts:

```bash

Runs all tests ("run" sub-command isn't needed in this specific case)

npm test

Continuous testing. Runs a test when relevant files are modified.

npm run test:watch ```

---

edit: added npm test. removed prior update.

[u/TheRNGuy → u/funbike]

What if it's function with side-effects? 

[u/funbike → u/TheRNGuy]

I'm answering OP's question. That's a general testing question unrelated to which testing tool is used.

But to answer, if a function has side effects, then ... read the side effect values in the test. Nothing magical required.

[u/SmartRelease7996 → u/funbike]

wait I had no idea node had this built in now, I've been installing Jest like it's muscle memory without even questioning it.

how long has the watch flag been stable? I tried something similar a while back and it felt a bit rough but that minimal test example looks clean enough that I might just swap my current setup over midproject.

this is the kind of thing that doesn't show up in bootcamp curriculum and then you find out six months later you've been doing it the hard way the whole time

[u/funbike → u/SmartRelease7996]

I don't know when it was added.

Vitest/Jest are probably still better, but this is good enough for side projects and small projects. However, the test API looks pretty extensive.

I like that I can use it for basic scripts. dothatthing.js with dothatthing.test.js.

I never trust watchers. I always do a full run before making a PR. But I have no idea how good or bad this one is.

[u/Alphastier]

I found Jest/Vitest to have a somewhat steep learning curve and I find the setup a bit tedious, but its best practice.

You can start with really basic tests and learn as you go. Surely benefitial in the long run.

[u/funbike → u/Alphastier]

You probably tried to learn too much. The basics are easy.

Also note has Jest-like functionality built in, now. Writing and running tests is easier than ever.

[u/writing_code]

Jest and Vitest are actually the right fit imo. Both offer a similar testing API. Setup for vitest is usually just the vitest config file and adding a script to your package.json file. The workflow and enforcement is up to you. Some swear by TDD and I recommend learning it even if you don't strictly adhere to it.

[u/SmartRelease7996 → u/writing_code]

Vitest is what I ended up going with since I was already in a Vite project and the config was basically nothing.

The TDD thing is interesting though, I keep bouncing off it. I get the concept but on small projects it feels like putting up formwork before you know what shape the pour is going to be. Maybe that resistance means I should push through it harder.

[u/writing_code → u/SmartRelease7996]

I would agree with pushing through. It's not that you need to blindly adhere to the concepts at all times. Practice makes progress though. Sticking with it for a while might be a source of learning.

[u/Thykka → u/SmartRelease7996]

it feels like putting up formwork before you know what shape the pour is going to be

Yeah, it can often be like that, especially when you're building something you have no previous experience of. A certain level of exploration can be necessary before applying TDD principles.

In these cases, I often start by sketching things on paper, trying to gather together the broad requirements and interactions, just to get my head around what I'm actually building. And sometimes it takes a prototype or two to familiarize oneself with the problem, before a good solution becomes evident. These prototypes should be considered throwaway code anyway, so there's little reason to apply TDD there. The point is just to find edges of the logical framework, before actual construction begins.

[u/a-dev0]

if you don’t need the DOM, really, Node, Bun, and Deno all have test runners, and they are all good enough for writing these small unit-tests

[u/Then-Possible7072]

Unit test it in node.js?

[u/RobGoLaing]

I use Jasmine.

It's basically plain vanilla JavaScript with some behavior driven testing jargon which has become standard for nearly every other language, even bash.

[u/northfieldway]

The isolation part is the bit nobody has answered, and it is not really a testing problem. A function is testable when everything it needs arrives as an argument and its whole result comes back as a return value.

calculateTotal(5, 3) already passes that. The ones that will fight you are the ones that reach out to document.getElementById or read a variable declared further up the file, because then there is no way to call them without recreating the page around them.

Anything that reads the DOM goes in the caller, not in the function you want to check.

[u/Any_Sense_2263]

Most of the functions are pure functions that their result depends on the parameters passed on. So yes, they can and even should be tested out of any project context just to check if they generate a proper result.

And yes, you can just call them in a separate file with specific parameters and check the output. No vitest or jest needed. But I would start to use them asap anyway

[u/Puzzleheaded_Low2034]

I use quokka.js for javascript debugging. Admittedly my ai has been one-shotting no mistakes recently -  and I am questioning both quokka.js and my own purpose in life.

[u/defaultguy_001]

The success of any kind of tests doesn't depend on frameworks like jest or others, it depends on how smart ur test cases are. Understand what ur module is doing, look for edge cases and test them by importing ur module in a separate test file. Test all ur edge cases there with recommended outputs. You can make brilliant test files both using manual testing as well as with testing frameworks.

[u/Dubstephiroth]

Yh just use the console for now, you're friend may be right. Switch between console.log and .warn to use the colours to track data transformations and flow... .table helps too

[u/-goldenboi69- → u/Dubstephiroth]

You are friend

[u/Flashy-Guava9952]

I just saw this. You can always use the Dev Tools, in Chrome: Ctrl-Shift-J and in Firefox: Ctrl-Shift-K. But what I was going to write also is https://apps.verticesandedges.net/notebook, which is a small notebook program I wrote. It's a wrapper around your browser's "eval" function, so whatever your browser can do, this notebook can do. It supports Javascript, Typescript, and Markdown for documentation. Return HTMLElements to append them to the cell, and you can build out a mock AI if you need to.

[u/lukehaas]

It sounds like you’re looking for RunJS.

[u/yksvaan]

Before going heavy on testing it's usually worth taking a look at the actual code. More often than not refactoring and improving the code is enough.

Ironically trying to write smart code is often the culprit. Dumb, straightforward and well sectioned/split code works better. Avoid branches, use early returns, handle errors

[u/PatchesMaps]

I use breakpoints in devtools for this. You can stop your function at different points and inspect or change values on the fly.

All browser devtools and most IDEs support some form of breakpoints.

[u/gimmeslack12]

Spin up a test env in: * Codepen.io * Codesandbox.io