Pythagora: LLM-generated Jest tests for Node.js, and the deprecation notice at the top of its README

The problem Pythagora targets: Node.js helpers with no tests

Most Node.js projects have a layer of small exported functions that nobody writes tests for. String formatters, date helpers, retry wrappers. They are easy to test in principle and tedious in practice, so coverage stays low and regressions slip through. Pythagora's stated mission is to make automated tests fully autonomous, and the README frames the workflow as one command followed by generated tests. The target user is a Node.js developer who already has functions exported from files and does not want to write the Jest boilerplate by hand. The README says the best results come from standalone functions, the parts of the code that can actually be unit tested, and points at its own src/utils/common.js as an example of a good candidate. That is a narrower audience than the repository topics (api-testing, database-testing, integration-testing) suggest, because the unit test path is what the main README documents, with integration tests pushed into a separate docs folder. If your code is mostly request handlers wired to a database, the unit test generator is not aimed at you.

AST parsing, a remote server, and what actually leaves your machine

The mechanism is described in three steps. Pythagora finds the function you asked about, then uses AST parsing to find every function called from inside it, then sends the target function plus all related functions to the Pythagora server, which generates tests with GPT-4. Two consequences follow from that data flow. First, the unit under test is not sent alone. Its transitive callees go with it, which is how the generated test can assert on behaviour that depends on helper logic, but it also means the payload grows with call depth. Second, generation is not local. The README states that code is sent to GPT and therefore to OpenAI, links OpenAI's privacy policy, and adds that Pythagora does not store your code on its servers. The server side is open sourced in a separate repository, and the prompts live in a prompts folder there, so the request format is inspectable. The README also notes a hard precondition: the function must be exported from its file. A non-exported function cannot be discovered, which rules out testing internal closures directly.

Commands, config keys, and the Jest-only constraint

Installation is a dev dependency: npm i pythagora --save-dev. You then store a key with npx pythagora --config --pythagora-api-key <API_KEY> or npx pythagora --config --openai-api-key <API_KEY>. Generation has four documented shapes. One function: npx pythagora --unit-tests --func <FUNCTION_NAME>. One function in a specific file: add --path ./path/to/file.js. Every function in a file: npx pythagora --unit-tests --path ./path/to/file.js. Every function in every file in a folder: npx pythagora --unit-tests --path ./path/to/folder/. There is a separate expansion mode, npx pythagora --expand-unit-tests --path <PATH_TO_YOUR_TEST_SUITE>, which accepts either a single test file or a folder and processes all test files inside it. Running the output is plain Jest: npx jest ./pythagora_tests/, or npx jest <PATH_TO_FILE_OR_FOLDER>. The README is explicit that only Jest generation is supported and invites email requests for other frameworks, so if your suite runs on Mocha or Vitest you would be porting the generated files by hand. On Windows the README requires Git Bash rather than PowerShell.

The deprecation line is the first thing on the page

The README opens with a deprecation notice: the repo is deprecated and the team is working on GPT Pilot. The repository metadata shows it is not archived and the last push is dated 2026-06-16, so the code is still present and the repository is not locked, but the maintainers' own framing is that this is not where active work happens. No releases were retrieved. For anyone evaluating adoption, that single line outweighs most of the feature list. You are looking at a CLI whose documented generation path depends on a separate server repository and on API keys, with no stated support commitment. That does not make the tool unusable. It makes it a tool you evaluate on a throwaway branch, and it makes the question of what happens when the API changes or the server stops answering the important one. The README does not address that scenario, and nothing in the supplied material describes a local generation mode that would survive it.

Where generated tests will disappoint you

The README's own numbers set expectations rather than promise quality. Running the generator against src/utils/common.js produced 145 tests, of which 17 failed; the README attributes 6 failures to incorrectly written tests and 11 to bugs the tests caught in the code. That is a mixed result: roughly one in eight generated tests did not pass on the first run, and most of those failures were real. A team that expects to run one command and commit the output will instead spend time triaging failures and deciding which ones are the test's fault. The second limitation is structural. Unit tests generated from a function and its callees do not exercise network calls, database state, or configuration that lives outside the parsed call graph. The repository topics mention api-testing and database-testing, but the main README routes integration tests to a separate document, and the unit test workflow described here will not cover those cases. Third, the README's own example of a good target is a helpers file, which is a candid admission that the tool is strongest exactly where writing tests was already easiest.

Compared with writing tests by hand or with a general coding assistant

The realistic alternative is not another test generator. It is a general-purpose coding assistant, or a developer writing the Jest file directly. The difference is in what gets selected as context. A general assistant typically works from whatever you paste or from files it can open in your editor, and you decide what matters. Pythagora decides for you: it walks the AST from the target function to its callees and sends that closure. That is a real advantage for a helper that calls four other helpers, because you do not have to trace the dependencies yourself. It is a disadvantage when the behaviour you care about depends on something the AST cannot see, such as a module-level constant or an injected client, because that context is simply not in the payload. Hand-written tests also let you pin exact expected values, while generated tests need review before they become a specification. The trade is speed of first draft against precision, and for a codebase with hundreds of small pure functions the first draft is the expensive part.

Licence, maintenance, and what upgrading costs you

Pythagora is Apache-2.0, which permits commercial use, modification, and redistribution provided you keep the licence and notice files and state significant changes. It also includes an explicit patent grant and a termination clause if you initiate patent litigation over the software. That is a permissive arrangement, and nothing in the supplied material suggests additional terms on the CLI itself. The practical cost is not the licence, it is the dependency on a remote generation service. Every run consumes tokens against either a Pythagora API key or your own OpenAI key, so cost scales with how many functions you point it at and how deep their call graphs go. The README does not publish per-run pricing or token estimates. Because the repository is marked deprecated and no releases were retrieved, there is no versioned upgrade path to plan around; you are tracking a moving main branch. The generated tests themselves live in ./pythagora_tests/ as ordinary Jest files, which is the one part of this setup that survives the tool going away. Treat the test output as the asset and the generator as disposable. This is a description of the licence terms, not legal advice.

Editorial conclusion

Pythagora is worth trying only if you are working in a Node.js codebase with exported, mostly standalone helper functions and you want a first pass at Jest coverage without writing it yourself, and even then you should treat it as a read-only experiment because the README's first line marks the repo deprecated in favor of GPT Pilot. Skip it if your tests must run against a live database or if you cannot send source code to OpenAI. Before running anything, check whether the Pythagora API endpoint is still reachable, since the CLI routes generation through a server that is open sourced separately, and decide which key you will configure with --pythagora-api-key or --openai-api-key.

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. Pythagora-io/pythagora on GitHub
5. README