DEV Community: Srinidhi Anand

AI is writing our code... but who is auditing the AI?

Srinidhi Anand — Sun, 26 Apr 2026 18:30:21 +0000

Hey Techies!

We all have certain steps to structuring and developing the code, ensuring it meets the business requirements. We structure patterns according to our project demands whether it's an application for an e-commerce site or a WordPress site. Code patterns can be of different types but developing code with certain patterns and asserting them in a way to handle edge cases, negative and positive cases improves the reliability in a better way. Handling millions of modules in a microservice architecture will be challenging and AI can support the developers to provide reliable code with good error management.

We all know the drill: scaling microservices with millions of modules is a nightmare for reliability. We need edge cases, negative tests, and perfect assertions, but who has the time?

This is where LLM Orchestration comes in. LLM orchestrated to support assertions of a code, that helps us to improve the code to handle low error rates and high efficiency. But I didn't want to build just another AI wrapper. The tool that assists us with this is ts-genai-test , which uses AST-based code analysis to automatically generate optimized Jest unit tests. It doesn't just call an AI; it calculates code complexity to route our requests to the most efficient LLM provider (Gemini, OpenAI, or Groq), saving us the costs while maximizing test accuracy.

So, AI writes the test cases with strictly engineered prompts, but who is auditing the auditor?

We need some assistance to audit the LLM suitable to run tests for the desired functions. An AST-based analyser builds a rapport in analysing the complexity of code to ensure the right function follows the right LLM to maintain efficient AI resources, with the input of the file path, file, and function inside the file. The library follows the code changes under staged changes to analyse the functions and files and runs the prompt to generate the ready-to-written test case code with defined import module syntax based on the exports like named and default functions.

Complexity Computation acts as not just a tool but a system of accountability to use AI resources. AI mode policy based on configuration named AI_OVERRIDE_POLICY that can accept suggest | auto | never to have a model selector override the user-defined model selection. Model selector acts as a digital supervisor, having logic combined with user preference like low-cost, high accuracy or balanced to decide the LLM based on the complexity score of a function to be asserted.

Complexity score categorized as above 60, range of 25-60, and below 25. AI model is chosen if user config doesn’t include the model or if the model has been configured with override policy as auto. Test tool generator chooses the recommended model; else, the user would be provided with suggestions to choose a model based on complexity score.

Low Complexity (< 25): Routes to gemini-1.5-flash (Low-cost).
Medium Complexity (25-60): Routes to gpt-4o-mini (Balanced).
High Complexity (> 60): Routes to gpt-4o (High-accuracy).

The Hallucination Problem: Hardening the Output

Let’s be honest: AI hallucinates. It guesses imports, misses function names, and sometimes generates code that looks right but doesn't run. In ts-genai-test tool, we don’t just hope for the best. We use Syntactic Hardening:

Deterministic Imports: We use AST analysis to tell the AI exactly how to import your functions. We don’t have to guess.
Strict Persona: The AI is locked into an Expert QA mode with hard constraints, no markdown, no conversational fluff, just raw TypeScript.
The Score of Truth: If a test doesn't pass the Jest suite, it’s flagged in our metrics. We close the loop between AI Generation and Real-world Execution.

With internal MetricsRunner, every run is audited. Users get a success rate, pass/fail counts, and actual coverage percentages. It’s not just AI-generated; it’s AI-accountable. The output json file would be in the user's project root folder level (refer to the image below).

The output of the result would be as follows:

Check it out on NPM ts-genai-test

If you find it helpful or have suggestions for improvement, I’d love your feedback.Thanks for reading, and happy coding! ✨

🚀 Stop Writing Jest Tests Manually — Generate Them with AI (TypeScript)

Srinidhi Anand — Mon, 05 Jan 2026 10:02:44 +0000

Writing unit tests is a best practice, but for many developers, it’s also repetitive, time-consuming, and easy to deprioritize as projects grow. In TypeScript backend projects, keeping Jest test coverage high often means spending significant time writing boilerplate rather than focusing on actual business logic.

To address this, I built ts-genai-test package, an AI-powered Jest test case generator for TypeScript (Node.js) that automatically generates meaningful unit tests using configurable Generative AI providers.

🔗 GitHub: testcase-gen-ai-ts
📦 npm: ts-genai-test

🧠 The Problem

Most developers face the same challenges when writing unit tests:

Writing repetitive Jest boilerplate
Missing edge cases due to time pressure
Tests becoming outdated after refactors
Spending more time testing than coding

Traditional test generators can scaffold files, but they don’t understand the intent of a function. Generative AI, on the other hand, can reason about function signatures and expected behavior, making it a natural fit for unit test generation. Let's get curious about it!

🤖 What is `ts-genai-test`?

ts-genai-test is a developer tool that:

Automatically generates Jest unit test cases
Works with TypeScript (Node.js) projects
Supports multiple AI providers
Allows configuration of model name and API key
Produces ready-to-run .test.ts files
Is designed to integrate cleanly into CI/CD workflows

The project is written in TypeScript, packaged using pnpm, and focuses on being simple, extensible, and developer-friendly.

✨ Key Features

✅ AI-Generated Jest Test Cases

Point the tool to a TypeScript file or function, and it generates Jest test cases automatically.

import path from "path";
import { generateTests, functionalTypes } from "ts-genai-test";
const inputPrompt: functionalTypes.PromptInput[] = [
  {
    outputTestDir: path.resolve(__dirname, "../__tests__"), // optional test suite directory, defaults to 'tests' folder
    folderPath: path.resolve(__dirname, "../src"),  // source folder
    filePath: path.resolve(__dirname, "../src/index"), // source file
    functionName: "add", // function to generate tests for
    testFileName: "" // optional custom test file name
    rootPath: "" // optional if outputTestDir is provided else its mandatory to form tests folder default path
  }
];

await generateTests(inputPrompt);

The generated output is clean, readable, and ready to execute—no manual cleanup required.

🧩 Override Existing Test Cases (Flag-Based Control)

By default, ts-genai-test is designed to preserve existing test files to avoid accidental overwrites. However, there are scenarios—such as refactoring or regenerating tests—where developers may want to rewrite existing test cases.

To support this, the tool provides an override test cases flag. When this flag is enabled:

Existing .test.ts files are explicitly overwritten
Previously generated or manually written tests can be replaced with newly generated ones
Developers retain full control over when regeneration is allowed

This flag-based approach ensures that test overwriting is intentional, explicit, and developer-controlled, reducing the risk of unintended changes while still enabling regeneration workflows.

This design reinforces the tool’s philosophy: AI assists test creation, but developers remain in control of the final output.

⚙️ Wide & Flexible AI Configuration

One of the core design goals of this project is configurability. You can configure model details (recommended via environment variables):

AI provider (OpenAI, Gemini, Groq, etc. in lowercase)[AI_MODEL=gemini]
Model code (or name) [AI_MODEL_NAME=gemini-2.5-flash]
API key [AI_API_KEY=*******]
Retry behavior for failed AI calls

This allows teams to switch providers easily, control costs, and future-proof their workflows as AI ecosystems evolve.

🔄 Built-In Retry Mechanism

AI calls can occasionally fail due to network issues or incomplete responses. To improve reliability, ts-genai-test includes a one-time retry mechanism that attempts regeneration before failing—making it safer to use in automated environments like CI pipelines.

🗂 Automatic Test Directory Handling

If the provided target test directory does not exist, the tool creates it automatically. This reduces setup friction and keeps the developer experience smooth.

🧪 Example

Given a simple utility function:

export function add(a: number, b: number): number {
  return a + b;
}

The tool generates a Jest test like:

test("adds two numbers", () => {
  expect(add(2, 3)).toBe(5);
});

Simple, readable, and immediately executable.

⚠️ Limitations

While ts-genai-test helps reduce the effort required to write unit tests, it is important to understand its current limitations:

Generated test cases should be reviewed before production use. AI-generated output is intended to assist developers, not to be used blindly.
Functions with complex business logic may require manual adjustments to ensure correctness and adequate coverage.
This tool assists developers; it does not replace human-written tests. Developer judgment remains essential for validating intent and edge cases.
Currently, only functional (unit-level) API test cases are supported. REST API testing, Swagger/OpenAPI-based test generation, and end-to-end API scenarios are not supported at this stage.

These limitations define the current scope of the project and also highlight clear opportunities for future enhancements.

🤝 Open Source & Collaboration

ts-genai-test is fully open source and welcomes collaboration. Contributions are especially welcome in areas like:

Supporting additional AI providers
Improving prompt quality
Adding support for other test frameworks
Exploring REST or Swagger-based test generation
Handle unsupported languages and malformed code
Support for non-TypeScript files

Documentation and examples

🔗 GitHub: testcase-gen-ai-ts GitHub Repo
📦 npm: ts-genai-test

🧰 Tech Stack

TypeScript
Node.js
pnpm (v10.24.0)
Jest
Generative AI (LLM-based test generation)

📦 Installation

Using pnpm (recommended):
pnpm install ts-genai-test

or using npm
npm install ts-genai-test

📌 Final Thoughts

This project explores how Generative AI can assist developers in writing better unit tests with less effort. While it does not replace thoughtful test design, it significantly reduces boilerplate and accelerates development.

If you’re working on TypeScript backends and spending too much time writing Jest tests, this tool might help and contributions are always welcome.

🧠🚀 Announcing helper-utils-ts — A Lightweight Utility Library for Clean Value Checks

Srinidhi Anand — Sat, 08 Nov 2025 11:07:35 +0000

Hey folks 👋

I recently published a small npm package called helper-utils-ts, and I wanted to share it with the community here on DEV. It solves something many of us run into pretty often — repetitive checks for null, undefined, and empty values scattered all over the codebase.

Why this library?

In multiple projects, I noticed I kept writing variations of:

if (value !== null && value !== undefined && value !== "") {
   // do something
}

This gets messy fast — especially in TypeScript projects where cleaner, readable checks are important.

So I extracted the checking logic into small reusable helpers and released them as a package.

No dependencies.
No setup.
Just simple helpers.

📦 Installation
npm install helper-utils-ts

Or if you're installing globally:
npm install -g helper-utils-ts

🧑‍💻 Usage Example

import { isUndefined, isNull, isEmpty } from "helper-utils-ts";

let foo;
console.log(isUndefined(foo)); // true

console.log(isNull(null)); // true

console.log(isEmpty("")); // true
console.log(isEmpty("null")); // true
console.log(isEmpty("undefined")); // true

🔍 How this differs from Lodash (and others)

Libraries like Lodash are extremely powerful, but they’re also large and general-purpose.

This package has a very focused goal:

Only handles value validation checks
Very small footprint
TypeScript-native with clean typings
Handles real-world edge cases (like "null" string from user input)

If you just need small readability helpers — this fits well.

If you're building full data pipelines — you probably want Lodash or Ramda.

🎯 Where this helps most

Input validation (frontend or backend)
Normalizing API or JSON payload values
Form processing and sanitization
Serverless / microservice environments where bundle size matters
Beginner-friendly or clarity-focused codebases

💬 Feedback appreciated!

This library is intentionally minimal — but it can grow if the community finds other practical helper patterns worth adding. Suggestions are welcome 🙌

NPM: helper-utils-ts package

Thanks for taking a look and happy coding! ✨