Radberi-TestingAntiPatterns

Identify and mitigate testing anti-patterns in .NET projects.

1|Updated Mar 20, 2026
One-click install
npx skills add https://github.com/Shade666/huml-dotnet --skill radberi-testingantipatterns
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Radberi-TestingAntiPatterns
Source: https://github.com/Shade666/huml-dotnet/tree/main/.claude/skills/Radberi-TestingAntiPatterns
Command: npx skills add https://github.com/Shade666/huml-dotnet --skill radberi-testingantipatterns

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Tests can drift into mocking real behaviour or polluting production with test-only methods; this Skill helps prevent those anti-patterns.

Core principle: Test what the code does, not what the mocks do.

Following strict TDD prevents these anti-patterns.

Core Features & Use Cases

  • Guidance on avoiding test-only methods, mocking pitfalls, and excessive mocks.
  • Real-world anti-pattern examples with fixes to improve test quality and maintainability.
  • Use Case: when writing or refactoring tests to ensure realistic verification and isolation.

Quick Start

Review your tests to ensure you validate real behaviour rather than mock behaviour and remove assertions that only check mocks.

Frequently Asked Questions about Radberi-TestingAntiPatterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What are common unit testing anti-patterns in C# and .NET?

You can avoid mocking pitfalls by following strict TDD, using real in-memory data stores, and applying lightweight test doubles to ensure your tests validate actual behavior rather than mock interactions.

Why do my unit tests validate mock behavior instead of real behavior?

Unit tests validate mock behavior instead of real behavior when they assert mock interactions or rely on excessive mocks, which drifts test verification away from actual application logic and strict TDD principles.

Does following strict TDD prevent test-only production code in .NET?

Yes, following strict TDD prevents test-only production code in .NET by ensuring tests drive real implementation, avoiding the need to pollute production code with methods existing solely for test access.

How do I refactor tests to use real in-memory data stores instead of mocks?

Refactor tests to use real in-memory data stores by replacing excessive mocks with lightweight test doubles and comprehensive DTO data structures, ensuring tests verify real behavior across unit and integration tests.

When should I not use mocking in dotnet unit testing?

You should not use mocking in dotnet unit testing when it causes incomplete mock setups or requires test-only production code, opting instead for real in-memory data stores to validate actual behavior.