agentleFS
MicrosoftKnown publishermicrosoft-foundry/foundry-agent-webapp/.github/skills/writing-unit-tests-csharp/SKILL.md

writing-unit-tests-csharp

Skill124 starsChanged 7 months agoMITView on GitHub

Guidelines and patterns for writing unit tests in C# using MSTest SDK.

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
  1. Very specific:

    Use descriptive names following: MethodName_Scenario_ExpectedBehavior

    line 101
  2. Very specific:

    Use the validating-ui-features skill and Playwright when:

    line 141

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 test

Test 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)

ClassWhat to Test
ErrorResponseFactoryStatus code mapping, dev vs prod mode, exception detail hiding
ChatRequestValidation logic if any
StreamChunkSerialization/deserialization
AnnotationInfoProperty mapping

Services (Require Integration Testing)

ClassTesting Approach
AgentFrameworkServiceUse 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

CommandPurpose
dotnet testRun all tests
dotnet test --filter "Name~Test"Run filtered tests
dotnet buildBuild without running
dotnet test --list-testsList all tests

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.