Top AI Repos — open-source AI, indexed and scored
Top AI Repos tracks AI repositories on GitHub and answers two different questions about each one: is it moving right now, and would you bet a product on it.
Top AI Repos tracks AI repositories on GitHub and answers two different questions about each one: is it moving right now, and would you bet a product on it.
📙 A guide to unit testing in Javascript
| Date | Stars |
|---|---|
| 2026-07-24 | 1966 |
| 2026-07-25 | 1966 |
| 2026-07-28 | 1966 |
| 2026-07-30 | 1966 |
| 2026-08-06 | 1966 |
Today
— stars today
This week
— stars this week
This month
— stars this month
Momentum
0.0
growth rate 0.00%/day
# A guide to unit testing in JavaScript **This is a living document. New ideas are always welcome. Contribute: fork, clone, branch, commit, push, pull request.** > All the information provided has been compiled & adapted from many references, some of them cited at the end of the document. > The guidelines are illustrated by my own examples, fruit of my personal experience writing and reviewing unit tests. > Many thanks to all of the sources of information & contributors. 📅 _Last edit: September 2025._ ## 📖 Table of contents 1. General principles - [Unit tests](#unit-tests) - [Design principles](#design-principles) 2. Guidelines - [Whenever possible, use TDD](#-whenever-possible-use-tdd) - [When applying TDD, always start by writing the simplest failing test](#-when-applying-tdd-always-start-by-writing-the-simplest-failing-test) - [When applying TDD, always make baby steps in each cycle](#-when-applying-tdd-always-make-baby-steps-in-each-cycle) - [Structure your tests properly](#-structure-your-tests-properly) - [Name your tests properly](#-name-your-tests-properly) - [Use the Arrange-Act-Assert pattern](#-use-the-arrange-act-assert-pattern) - [Avoid logic in your tests](#-avoid-logic-in-your-tests) - [Don't write unnecessary expectations](#-dont-write-unnecessary-expectations) - [Test the behaviour, not the internal implementation](#-test-the-behaviour-not-the-internal-implementation) - [Consider using factory functions](#-consider-using-factory-functions) - [Don't test multiple concerns in the same test](#-dont-test-multiple-concerns-in-the-same-test) - [Cover the general case and the edge cases](#-cover-the-general-case-and-the-edge-cases) - [Use dependency injection](#-use-dependency-injection) - [Don't mock everything](#-dont-mock-everything) - [Use realistic, production-like, data](#-use-realistic-production-like-data) - [Don't write unit tests for complex user interactions](#-dont-write-unit-tests-for-complex-user-interactions) - [Test simple user actions](#-test-simple-user-actions) - [Create new tests for every defect](#-create-new-tests-for-every-defect) - [Don't comment out tests](#-dont-comment-out-tests) - [Know your testing framework API](#-know-your-testing-framework-api) - [Review test code first](#-review-test-code-first) - [Practice code katas, learn with pair programming](#-practice-code-katas-learn-with-pair-programming) 3. [Resources](#-resources) 4. [Translations](#-translations) 5. [Contributors](#-contributors) ## ⛩️ General principles ### Unit tests **Unit = Unit of work** The work can involve **multiple methods and classes**, invoked by some public API that can: - Return a value or throw an exception - Change the state of the system - Make 3rd party calls (API, database, ...) A unit test should test the behaviour of a unit of work: for a given input, it expects an end result that can be any of the above. **Unit tests are isolated and independent of each other** - Any given behaviour should be specified in **one and only one test** - The execution/order of execution of one test **cannot affect the others** The code is designed to support this independence (see "Design principles" below). **Unit tests are lightweight tests** - Repeatable - Fast - Consistent - Easy to write and read **Unit tests are code too** They should be easily **readable** and **maintainable**. Don't hesitate to refactor them to help your future self. For instance, it should be trivial to understand why a test is failing just by looking at its own code, without having to search in many places in the test file (variables declared in the top-level scope, closures, test setup & teardown hooks, etc.). • [Back to ToC](#-table-of-contents) • ### Design principles The key to good unit testing is to write **testable code**. Applying simple design principles can help, in particular: - Use a **good, consistent naming convention**.
Excerpt of 31,484 characters
Read on GitHub
54
1
1
1
1
Would you bet a product on this? Bounded 0–100 and slow moving.
matched fp:834f3995659b6666, topic:testing