writing-unit-tests-csharp
Skill124 starsChanged 7 months agoMITView on GitHub
Guidelines and patterns for writing unit tests in C# using MSTest SDK.
In this repository20 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- committing-codeSkill
- deploying-to-azureSkill
- implementing-chat-streamingSkill
- planning-featuresSkill
- researching-azure-ai-sdkSkill
- reviewing-documentationSkill
- syncing-mcp-serversSkill
- testing-cli-compatibilitySkill
- testing-with-playwrightSkill
- triaging-issuesSkill
- troubleshooting-authenticationSkill
- understanding-architectureSkill
- validating-deploymentsSkill
- validating-local-setupSkill
- validating-ui-featuresSkill
- writing-bicep-templatesSkill
- writing-csharp-codeSkill
- writing-typescript-codeSkill
- writing-unit-tests-typescriptSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 101
Use descriptive names following: MethodName_Scenario_ExpectedBehavior
- Very specific: line 141
Use the validating-ui-features skill and Playwright when:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Skill: Writing C# Unit Tests
Overview
This skill covers writing unit tests for the backend using MSTest SDK. The project uses a lean, zero-config approach that leverages Microsoft's official SDK-style testing.
Project Structure
backend/
├── WebApp.sln
├── WebApp.Api/
│ ├── Models/ # DTOs and request/response models
│ ├── Services/ # Business logic and agent integration
│ └── Program.cs # Minimal API endpoints
└── WebApp.Api.Tests/
├── WebApp.Api.Tests.csproj
└── [TestClass].cs # Test files organized by class under testTest Project Configuration
The test project uses MSTest SDK which eliminates the need for explicit package references:
See backend/WebApp.Api.Tests/WebApp.Api.Tests.csproj for current configuration. The project uses MSTest SDK which eliminates the need for explicit package references — just set Sdk="MSTest.Sdk/{version}" in the project element.
Test Anatomy
using WebApp.Api.Models;
namespace WebApp.Api.Tests;
[TestClass]
public class ErrorResponseFactoryTests
{
[TestMethod]
public void CreateFromException_ReturnsCorrectStatusCode()
{
// Arrange
var exception = new InvalidOperationException("Test");
// Act
var result = ErrorResponseFactory.CreateFromException(exception, 500, isDevelopment: false);
// Assert
Assert.AreEqual(500, result.Status);
}
[TestMethod]
[DataRow(400, "Bad Request")]
[DataRow(401, "Unauthorized")]
[DataRow(500, "Internal Server Error")]
public void CreateFromException_MapsStatusToTitle(int status, string expectedTitle)
{
// Parameterized test using DataRow
}
}Running Tests
# Run all backend tests
cd backend
dotnet test
# Run with verbose output
dotnet test --verbosity normal
# Run specific test class
dotnet test --filter "FullyQualifiedName~ErrorResponseFactoryTests"
# Run with coverage (requires coverlet)
dotnet test --collect:"XPlat Code Coverage"Testable Units in This Project
Models (Pure, Easy to Test)
| Class | What to Test |
ErrorResponseFactory | Status code mapping, dev vs prod mode, exception detail hiding |
ChatRequest | Validation logic if any |
StreamChunk | Serialization/deserialization |
AnnotationInfo | Property mapping |
Services (Require Integration Testing)
| Class | Testing Approach |
AgentFrameworkService | Use validating-ui-features skill with Playwright for integration tests |
Test Naming Convention
Use descriptive names following: MethodName_Scenario_ExpectedBehavior
[TestMethod]
public void CreateFromException_WhenDevelopmentMode_IncludesStackTrace() { }
[TestMethod]
public void CreateFromException_WhenProductionMode_HidesStackTrace() { }Assertions Reference
MSTest provides these assertion methods:
// Equality
Assert.AreEqual(expected, actual);
Assert.AreNotEqual(notExpected, actual);
// Nullability
Assert.IsNull(value);
Assert.IsNotNull(value);
// Boolean
Assert.IsTrue(condition);
Assert.IsFalse(condition);
// Type
Assert.IsInstanceOfType(obj, typeof(ExpectedType));
// Collections
CollectionAssert.Contains(collection, element);
CollectionAssert.AreEqual(expected, actual);
// Exceptions
Assert.ThrowsException<InvalidOperationException>(() => MethodThatThrows());When Unit Tests Aren't Enough
Use the validating-ui-features skill and Playwright when:
- Testing requires a running backend server
- Testing SSE streaming behavior
- Testing authentication flows
- Testing the full chat request/response cycle
Quick Reference
| Command | Purpose |
dotnet test | Run all tests |
dotnet test --filter "Name~Test" | Run filtered tests |
dotnet build | Build without running |
dotnet test --list-tests | List all tests |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

