Why Your Tests Are Useless: Testing Anti-Patterns

Stop wasting time on bad tests

I'll never forget the day our entire test suite turned green while production was literally on fire.

It was 2 AM. My phone wouldn't stop buzzing. Users couldn't log in. The payment system was down. And there I was, staring at my laptop screen showing 847 passing tests with those beautiful green checkmarks mocking me. That's when I realized: we'd been lying to ourselves for months.

The Comfortable Lie We Tell Ourselves

You know that warm, fuzzy feeling you get when you see "All tests passed"? Yeah, I was addicted to that feeling. Our team had 90% code coverage. We had unit tests, integration tests, even some end-to-end tests. On paper, we were doing everything right.

But here's the thing nobody tells you about testing: having tests doesn't mean you're actually testing anything useful.

I learned this the hard way when Sarah from customer support forwarded me an email from a user who'd been trying to purchase our premium plan for three days. Three. Days. And our tests? Still green. Still passing. Still completely useless.

The problem wasn't that we didn't have tests. We had plenty. The problem was that we'd fallen into every testing anti-pattern in the book, and we didn't even know it.

The Hall of Shame: My Greatest Testing Failures

Let me walk you through the disasters I've created, so you don't have to.

Anti-Pattern #1: The "Testing for Coverage" Trap

Here's what our tests looked like when I was chasing that magical 100% coverage number:

describe('UserService', () => {
  it('should create a user', () => {
    const userService = new UserService();
    const result = userService.createUser('John', 'john@example.com');
    expect(result).toBeDefined();
  });
});

Look at that test. It's beautiful, isn't it? It runs. It passes. It increases our coverage percentage. And it's completely worthless.

This test doesn't verify that the user was actually created. It doesn't check if the email is valid. It doesn't ensure the user was saved to the database. It just checks that something came back. Congratulations, we've tested that our function returns... something. Anything. Even an error object would make this test pass.

I wrote dozens of these. They made me feel productive. They made our metrics look good. And they caught exactly zero bugs.

Anti-Pattern #2: The Fragile Test That Cries Wolf

Then there was the test that broke every single time someone breathed near the codebase:

it('should display user dashboard', async () => {
  render(<Dashboard />);

  await waitFor(() => {
    expect(screen.getByText('Welcome, John Doe')).toBeInTheDocument();
    expect(screen.getByTestId('sidebar-menu-item-1')).toBeInTheDocument();
    expect(screen.getByTestId('sidebar-menu-item-2')).toBeInTheDocument();
    expect(screen.getByTestId('notification-badge')).toHaveTextContent('3');
    expect(screen.getByClassName('dashboard-grid-layout')).toHaveStyle('display: grid');
  });
});

This test was so brittle that changing a CSS class name would break it. Reordering menu items? Broken. Changing "John Doe" to "John Smith" in the test data? Broken. Someone sneezing in the next room? Probably broken.

We got so used to this test failing that we stopped paying attention. "Oh, that's just the dashboard test being weird again," we'd say, and merge our PRs anyway. Until one day, it was failing for a real reason, and we ignored it. That's how a critical bug made it to production.

Anti-Pattern #3: The Test That Tests Nothing

My personal favorite disaster was this gem:

describe('Payment Processing', () => {
  it('should process payment successfully', () => {
    const paymentService = new PaymentService();
    jest.spyOn(paymentService, 'processPayment').mockResolvedValue({ success: true });

    const result = paymentService.processPayment(100, 'USD');
    expect(result).resolves.toEqual({ success: true });
  });
});

Do you see it? We're mocking the exact function we're trying to test. We're literally saying, "Hey, when this function is called, just pretend it worked." Then we test that... it pretended to work. This is like asking yourself if you're a good cook, answering yes, and then celebrating your culinary skills.

This was the test that was passing while our payment system was down. We'd mocked away the entire payment gateway integration, so our tests had no idea that the actual API was returning errors.

The Wake-Up Call

After the 2 AM incident, I spent the entire weekend rewriting our test suite. Not adding more tests—actually, I deleted about 40% of them. Here's what I learned.

What Actually Works: Testing Behavior, Not Implementation

Here's how I rewrote that user creation test:

describe('UserService', () => {
  it('should create a user with valid email and save to database', async () => {
    const userService = new UserService(testDatabase);

    const user = await userService.createUser('John', 'john@example.com');

    expect(user.name).toBe('John');
    expect(user.email).toBe('john@example.com');
    expect(user.id).toBeDefined();

    // Verify it's actually in the database
    const savedUser = await testDatabase.users.findById(user.id);
    expect(savedUser).toEqual(user);
  });

  it('should reject invalid email addresses', async () => {
    const userService = new UserService(testDatabase);

    await expect(
      userService.createUser('John', 'not-an-email')
    ).rejects.toThrow('Invalid email address');
  });
});

See the difference? Now we're testing actual behavior. We're verifying that the user gets saved. We're checking error cases. This test would have caught real bugs.

Making Tests Resilient

For that fragile dashboard test, I learned to focus on user-facing behavior, not implementation details:

it('should display personalized dashboard for logged-in user', async () => {
  const user = { name: 'John Doe', notifications: 3 };
  render(<Dashboard user={user} />);

  // Test what users actually see and care about
  expect(screen.getByRole('heading', { name: /welcome/i })).toBeInTheDocument();
  expect(screen.getByRole('navigation')).toBeInTheDocument();
  expect(screen.getByLabelText(/notifications/i)).toHaveTextContent('3');
});

This test doesn't care about CSS classes or test IDs. It doesn't care if we reorder menu items. It tests what a user would actually experience: Can they see their name? Is there a navigation menu? Can they see their notifications?

Testing Real Integration Points

And for that payment test? I stopped mocking the things that actually matter:

describe('Payment Processing', () => {
  it('should successfully charge customer and record transaction', async () => {
    // Use a test payment gateway, not a mock
    const paymentService = new PaymentService(testPaymentGateway);

    const result = await paymentService.processPayment({
      amount: 100,
      currency: 'USD',
      cardToken: TEST_CARD_TOKEN
    });

    expect(result.success).toBe(true);
    expect(result.transactionId).toBeDefined();

    // Verify the transaction was recorded
    const transaction = await database.transactions.findById(result.transactionId);
    expect(transaction.amount).toBe(100);
    expect(transaction.status).toBe('completed');
  });
});

Yes, this test is slower. Yes, it requires more setup. But it would have caught that production bug.

The Hard Truths I Had to Accept

After months of rewriting and rethinking our testing strategy, here's what I wish someone had told me from the start:

Coverage is a vanity metric. I used to brag about our 90% coverage. Now I'd rather have 60% coverage with tests that actually matter. Quality over quantity isn't just a cliché—it's the difference between catching bugs and fooling yourself.

If your test doesn't fail when the code is broken, delete it. Seriously. I started doing this exercise: I'd intentionally break something and see which tests failed. If a test didn't fail when its corresponding code was broken, that test was lying to me.

Mock sparingly, test reality generously. Mocks are useful for external services you don't control (like third-party APIs), but mocking your own code is usually a sign you're testing the wrong thing. I now follow this rule: mock at the boundaries, test everything else for real.

Slow tests are better than wrong tests. Yes, our test suite takes longer to run now. But I sleep better at night. I'll take a 10-minute test suite that catches bugs over a 30-second test suite that gives me false confidence any day.

The Transformation

Six months after our testing overhaul, we had fewer tests but caught more bugs. Our test suite went from 847 tests to about 600, but those 600 tests actually meant something. When they passed, I could trust them. When they failed, I paid attention.

We haven't had a 2 AM emergency since then. Well, we had one, but our tests caught it before it reached production. That's the difference.

Your Turn

Look, I'm not saying you should delete all your tests and start over (though honestly, that's what I did). But I am saying this: open up your test suite right now and ask yourself honestly—if these tests are passing, does that actually mean your code works?

If the answer makes you uncomfortable, good. That discomfort is the first step toward writing tests that actually matter.

Stop chasing coverage percentages. Stop writing tests that make you feel good. Start writing tests that would make you look bad if they passed while your code was broken.

Your future self—the one who won't be woken up at 2 AM—will thank you.