The Bug Was Fixed. Then It Came Back.

That is usually the moment testing stops feeling optional — when a fix you shipped with confidence walks back into production wearing a different ticket number.

In a .NET application, unit tests protect the small pieces of logic that should behave the same every time. Calculations, validation rules and service methods can be tested quickly without involving the database or the rest of the application. xUnit or NUnit with a mocking library like Moq or NSubstitute is usually enough — the point is that they run in milliseconds so you actually run them.

But code rarely fails in isolation.

An API endpoint may call the correct service and still save the wrong data. Authentication may work until a real request reaches the application. Entity Framework may behave differently from the mocked repository used in a unit test. The suite that only mocks everything will keep glowing green while production argues with reality.

Then there is regression testing — the boring one, until a bug you fixed three months ago suddenly returns on a Friday afternoon.

Whenever a defect is found, the fix should include a test that reproduces it first. A red test that turns green is proof the issue is solved. Left in the suite, it becomes a warning system for any future change that tries to bring the bug back.

A practical pyramid for .NET teams

1. 01

   Unit tests

   Protect the rules — calculations, validation, service logic. Fast, isolated, run on every save.

2. 02

   Integration tests

   Protect the connections — API, EF Core, auth, config, external calls. Run on every push.

3. 03

   Regression tests

   Protect the lessons — every fixed bug earns a permanent test. Run on every release.

• Prefer testing behaviour over implementation details — rename a private method and the suite should still sleep.
• Keep unit tests ruthless about speed; park slow I/O in integration where it belongs.
• Treat flaky tests as production bugs: quarantine, fix or delete — never “retry until green”.
• When a bug escapes, write the failing test before the patch. That habit compounds.

A useful .NET test suite is not measured by how many tests it contains. It is measured by what it protects.

“Unit tests protect the rules. Integration tests protect the connections. Regression tests protect the lessons the project has already paid to learn.”

The goal is not to test every line of code. It is to make changes without constantly wondering what else might have broken.