How to Test Private Methods in TypeScript

Every software engineer writing unit tests eventually faces this dilemma: you write a complex class with a private helper method, and you want to write a direct unit test for that specific logic.

When you try to call service.handleError() in your test file, the TypeScript compiler blocks you:

Property 'handleError' is private and only accessible within class 'ProductService'.

Is testing private methods an anti-pattern? What are your options when you have to test critical internal logic?

In this post, I will show you four ways to test private methods in TypeScript, explain the crucial difference between TypeScript private and JavaScript #private fields, and discuss when to refactor.

The Example: A Service with a Private Error Handler

Consider this Angular or Node.js service that handles HTTP requests and formats errors internally:

import { Injectable, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { firstValueFrom } from 'rxjs';
 
@Injectable({ providedIn: 'root' })
export class ProductService {
  #http = inject(HttpClient);
 
  async getProducts(): Promise<string[]> {
    try {
      const response = await firstValueFrom(
        this.#http.get<{ data: string[] }>('/api/products')
      );
      return response.data;
    } catch (error) {
      const formatted = this.formatErrorMessage(error as Error);
      console.error(formatted);
      return [];
    }
  }
 
  private formatErrorMessage(error: Error): string {
    return `[ProductService Error]: ${error.message}`;
  }
}

The method formatErrorMessage is marked as private. Let us review the four strategies to test it.

Strategy 1: Bracket Notation (The Pragmatic Shortcut)

TypeScript's private keyword is purely a compile-time check. Once your TypeScript compiles to JavaScript, the private keyword disappears completely.

At runtime, standard TypeScript private methods are normal JavaScript properties on the object prototype. You can bypass the compiler check using string index access:

import { ProductService } from './product.service';
 
describe('ProductService', () => {
  it('should format error messages correctly', () => {
    const service = new ProductService();
    const testError = new Error('Database connection failed');
 
    // Bypass TypeScript compiler check using bracket notation
    const result = service['formatErrorMessage'](testError);
 
    expect(result).toBe('[ProductService Error]: Database connection failed');
  });
});

You can also cast the instance to any:

const result = (service as any).formatErrorMessage(testError);

When to use this:

Use this when you are working on legacy code and need quick test coverage without refactoring production classes.

Warning: This only works with TypeScript's private keyword. It will NOT work with JavaScript #private fields!

Crucial Gotcha: TypeScript private vs JavaScript #private

Many developers confuse TypeScript's private keyword with native JavaScript private fields (#methodName).

export class ModernService {
  // TypeScript compile-time private
  private tsPrivate(): string {
    return 'Accessible via bracket notation';
  }
 
  // ECMAScript runtime private field
  #jsPrivate(): string {
    return 'Enforced by the JS engine';
  }
}

If your class uses #formatErrorMessage, bracket notation will fail. That brings us to our cleaner, architectural solutions.

Strategy 2: Extracting to Standalone Pure Helper Functions (Recommended)

When a private method contains non-trivial business logic, calculations, or string formatting, it usually does not belong inside the class itself.

Move the helper logic to a standalone pure function in the same file or a utility file:

// product.utils.ts
export function formatErrorMessage(error: Error): string {
  return `[ProductService Error]: ${error.message}`;
}

Then use the function inside your service:

import { formatErrorMessage } from './product.utils';
 
export class ProductService {
  private format(error: Error) {
    return formatErrorMessage(error);
  }
}

Now you can test formatErrorMessage directly without needing any class instances, mock dependencies, or type casting:

import { formatErrorMessage } from './product.utils';
 
describe('formatErrorMessage', () => {
  it('formats error with prefix', () => {
    const error = new Error('Network timeout');
    expect(formatErrorMessage(error)).toBe('[ProductService Error]: Network timeout');
  });
});

This approach creates code that is easier to test, reuse, and maintain.

Strategy 3: Using protected and a Test Sandbox Subclass

If the method must access internal protected state on the class instance, change the modifier from private to protected.

Then, in your test file, create a test subclass that exposes the protected method publicly:

// In your test file:
class TestableProductService extends ProductService {
  public exposeFormatErrorMessage(error: Error): string {
    return this.formatErrorMessage(error);
  }
}
 
describe('ProductService with Subclass Sandbox', () => {
  it('exposes protected method for verification', () => {
    const testService = new TestableProductService();
    const result = testService.exposeFormatErrorMessage(new Error('Auth failed'));
 
    expect(result).toBe('[ProductService Error]: Auth failed');
  });
});

This pattern keeps the method hidden from consumer code while giving your test suite a type-safe entry point.

Strategy 4: Testing Through Public Methods (Behavioral Testing)

The purest philosophy in testing is: test behavior, not implementation details.

Instead of testing formatErrorMessage directly, test the public getProducts() method and verify its observable output when an error occurs:

it('returns empty array and logs error when request fails', async () => {
  const consoleSpy = jest.spyOn(console, 'error').mockImplementation();
  
  // Arrange mock to reject
  mockHttp.get.mockReturnValue(throwError(() => new Error('Server 500')));
 
  const products = await service.getProducts();
 
  expect(products).toEqual([]);
  expect(consoleSpy).toHaveBeenCalledWith('[ProductService Error]: Server 500');
  
  consoleSpy.mockRestore();
});

By testing the public contract, your tests will not break if you later refactor or rename internal private methods.

Summary Comparison

My Recommendation:

• For existing code: Use bracket notation or test the public method.
• For new code: Extract complex logic into pure functions and test them directly.

Conclusion & Next Steps

Testing private methods in TypeScript comes down to choosing the right tool for the job:

1. Remember compile vs runtime: TypeScript private disappears at runtime, but #private is permanently protected.
2. Prefer public behavior: Test what the user or consumer sees, not internal wiring.
3. Extract pure logic: Pure functions without class side-effects are always the easiest to test.

If you found this guide helpful, check out these related TypeScript and testing articles:

• Why Avoid Using 'any' in TypeScript
• How and When to Use Mocks or Spies in Unit Testing
• Abstract Classes in TypeScript
• How to Check Types in TypeScript