Testing AI Agent Workflows in .NET: Validation Patterns

Why Testing AI Agents Matters Differently

Building AI agents is different from building traditional APIs. With conventional software, you control the logic flow. With agents, the model decides which tool to call, when to call it, and how to handle outputs. That flexibility is powerful, but it introduces new testing challenges.

An agent might call tools in an unexpected order, misinterpret tool outputs, or get stuck in a loop. A tool might return data the agent doesn’t know how to handle. The agent might produce results that look reasonable on the surface but are actually incorrect. These issues emerge from the interaction between the model, the tools, and the workflow logic, so they’re different from traditional bugs.

Testing AI agents requires a layered approach: validating individual tools, verifying workflow state transitions, testing agent-to-agent communication, and running end-to-end scenarios with real inputs. Each layer validates a different aspect of the system.

Layer 1: Validating MCP Tools with MCP Inspector

The Model Context Protocol (MCP) is how agents interact with external tools. Before an agent ever touches a tool, you need to verify that the tool itself works correctly and exposes the right interface.

MCP Inspector is a built-in debugging tool that lets you test tools in isolation. It’s your first line of defense.

Start by running your MCP server locally:

dotnet run --project YourMcpServer

Then in another terminal, connect MCP Inspector to your server:

npx @modelcontextprotocol/inspector npx dotnet run --project YourMcpServer

MCP Inspector opens a web interface where you can call your tools directly, see the exact request and response payloads, and verify that your tool definitions match what the agent will receive.

When testing tools this way, look for:

• Tool names and descriptions are clear and unambiguous
• Input schemas are correct JSON Schema and match your actual parameters
• Responses include all data the agent needs to make decisions
• Error responses are structured and informative, not raw exceptions
• Response times are reasonable (agents have timeout limits on tool calls)

For example, if you have a tool that queries a database, test it with MCP Inspector first. Call it with valid inputs, invalid inputs, empty results, and edge cases. Watch the response structure. If the tool returns raw database errors instead of structured responses, fix that before the agent tries to use it.

Layer 2: Unit Testing Tool Implementations

MCP Inspector is manual and interactive. For automated testing, write unit tests for your tool implementations themselves.

Here’s a practical pattern using xUnit:

public class CustomerLookupToolTests
{
    private readonly CustomerLookupTool _tool;
    private readonly Mock<ICustomerRepository> _mockRepository;

    public CustomerLookupToolTests()
    {
        _mockRepository = new Mock<ICustomerRepository>();
        _tool = new CustomerLookupTool(_mockRepository.Object);
    }

    [Fact]
    public async Task Execute_WithValidCustomerId_ReturnsCustomerData()
    {
        var customerId = "CUST-12345";
        var customer = new Customer
        {
            Id = customerId,
            Name = "Acme Corp",
            Status = "Active",
            LastOrderDate = DateTime.UtcNow.AddDays(-30)
        };

        _mockRepository.Setup(r => r.GetCustomerAsync(customerId))
            .ReturnsAsync(customer);

        var input = new { customerId = customerId };
        var result = await _tool.ExecuteAsync(input);

        Assert.NotNull(result);
        Assert.Contains("Acme Corp", result);
        Assert.Contains("Active", result);
    }

    [Fact]
    public async Task Execute_WithMissingCustomer_ReturnsStructuredNotFound()
    {
        var customerId = "NONEXISTENT";
        _mockRepository.Setup(r => r.GetCustomerAsync(customerId))
            .ReturnsAsync((Customer)null);

        var input = new { customerId = customerId };
        var result = await _tool.ExecuteAsync(input);

        Assert.NotNull(result);
        Assert.Contains("not found", result.ToLower());
    }

    [Theory]
    [InlineData(null)]
    [InlineData("")]
    [InlineData("   ")]
    public async Task Execute_WithInvalidCustomerId_ReturnsValidationError(string invalidId)
    {
        var input = new { customerId = invalidId };
        var result = await _tool.ExecuteAsync(input);

        Assert.NotNull(result);
        Assert.Contains("invalid", result.ToLower());
    }
}

The key insight here is that you’re testing the tool in isolation, with controlled inputs and mocked dependencies. This catches bugs in the tool logic before the agent ever runs. If a tool fails a unit test, you’ll know exactly where the problem is and can fix it quickly.

Layer 3: Workflow State Verification

Agents maintain state as they work through a task. They start with an initial request, call tools, receive results, decide what to do next, and eventually produce a final response. Testing this state flow is crucial.

Create a test that verifies the agent follows the expected workflow:

public class OrderProcessingAgentWorkflowTests
{
    private readonly OrderProcessingAgent _agent;
    private readonly Mock<IOrderService> _mockOrderService;
    private readonly Mock<IInventoryService> _mockInventoryService;
    private readonly Mock<INotificationService> _mockNotificationService;

    public OrderProcessingAgentWorkflowTests()
    {
        _mockOrderService = new Mock<IOrderService>();
        _mockInventoryService = new Mock<IInventoryService>();
        _mockNotificationService = new Mock<INotificationService>();

        _agent = new OrderProcessingAgent(
            _mockOrderService.Object,
            _mockInventoryService.Object,
            _mockNotificationService.Object
        );
    }

    [Fact]
    public async Task ProcessOrder_WithValidInput_FollowsExpectedWorkflow()
    {
        var orderId = "ORD-001";
        var order = new Order { Id = orderId, Status = "Pending", Total = 500m };
        var inventory = new InventoryCheck { Available = true, Quantity = 10 };

        _mockOrderService.Setup(s => s.GetOrderAsync(orderId))
            .ReturnsAsync(order);

        _mockInventoryService.Setup(s => s.CheckAvailabilityAsync(order.Items))
            .ReturnsAsync(inventory);

        _mockOrderService.Setup(s => s.UpdateStatusAsync(orderId, "Confirmed"))
            .ReturnsAsync(true);

        var result = await _agent.ProcessOrderAsync(orderId);

        Assert.NotNull(result);
        Assert.Equal("Confirmed", result.Status);

        _mockOrderService.Verify(s => s.GetOrderAsync(orderId), Times.Once);
        _mockInventoryService.Verify(s => s.CheckAvailabilityAsync(It.IsAny<List<OrderItem>>()), Times.Once);
        _mockOrderService.Verify(s => s.UpdateStatusAsync(orderId, "Confirmed"), Times.Once);
        _mockNotificationService.Verify(s => s.SendAsync(It.IsAny<Notification>()), Times.Once);
    }

    [Fact]
    public async Task ProcessOrder_WithoutInventory_SkipsConfirmationAndNotifies()
    {
        var orderId = "ORD-002";
        var order = new Order { Id = orderId, Status = "Pending", Total = 500m };
        var inventory = new InventoryCheck { Available = false, Quantity = 0 };

        _mockOrderService.Setup(s => s.GetOrderAsync(orderId))
            .ReturnsAsync(order);

        _mockInventoryService.Setup(s => s.CheckAvailabilityAsync(order.Items))
            .ReturnsAsync(inventory);

        var result = await _agent.ProcessOrderAsync(orderId);

        Assert.NotNull(result);
        Assert.Equal("BackOrder", result.Status);

        _mockOrderService.Verify(s => s.UpdateStatusAsync(orderId, "Confirmed"), Times.Never);
        _mockNotificationService.Verify(s => s.SendAsync(It.IsAny<Notification>()), Times.Once);
    }
}

This test verifies that the agent calls tools in the right order and makes the right decisions based on tool outputs. The verify calls check that the agent called the expected tools and skipped the ones it shouldn’t have. This catches workflow logic errors like skipped steps or incorrect branching.

Layer 4: Testing Missing-Input Handling

Agents sometimes receive incomplete or ambiguous user inputs. How does your agent respond? Does it ask clarifying questions? Does it use defaults? Does it handle it gracefully?

Test these scenarios explicitly:

public class MissingInputHandlingTests
{
    private readonly DataAnalysisAgent _agent;

    public MissingInputHandlingTests()
    {
        _agent = new DataAnalysisAgent();
    }

    [Fact]
    public async Task AnalyzeData_WithMissingDateRange_RequestsClarification()
    {
        var request = "Show me sales trends";
        var response = await _agent.ProcessRequestAsync(request);

        Assert.NotNull(response);
        Assert.Contains("date", response.ToLower());
        Assert.True(response.RequiresClarification);
    }

    [Fact]
    public async Task AnalyzeData_WithMissingMetric_UsesDefaultMetric()
    {
        var request = "Show me sales from January to March";
        var response = await _agent.ProcessRequestAsync(request);

        Assert.NotNull(response);
        Assert.False(response.RequiresClarification);
        Assert.Contains("Revenue", response.Analysis);
    }

    [Fact]
    public async Task AnalyzeData_WithConflictingInputs_PrioritizesAndNotifies()
    {
        var request = "Show me Q1 sales from January to March";
        var response = await _agent.ProcessRequestAsync(request);

        Assert.NotNull(response);
        Assert.Contains("using Q1", response.Analysis);
        Assert.Contains("note", response.Warnings.First().ToLower());
    }
}

These tests ensure your agent handles real-world inputs that don’t fit the happy path. Users will provide incomplete information, and your agent needs to respond in a way that makes sense for your use case.

Layer 5: Agent-to-Agent Communication Testing

If you have multiple agents that coordinate with each other, test that communication explicitly.

public class AgentCoordinationTests
{
    private readonly OrderAgent _orderAgent;
    private readonly BillingAgent _billingAgent;
    private readonly Mock<IAgentBus> _mockAgentBus;

    public AgentCoordinationTests()
    {
        _mockAgentBus = new Mock<IAgentBus>();
        _orderAgent = new OrderAgent(_mockAgentBus.Object);
        _billingAgent = new BillingAgent(_mockAgentBus.Object);
    }

    [Fact]
    public async Task OrderAgent_SendsCorrectMessageToBillingAgent()
    {
        var orderId = "ORD-123";
        var order = new Order { Id = orderId, Total = 1500m, Items = new List<OrderItem>() };

        var capturedMessage = null as AgentMessage;
        _mockAgentBus.Setup(b => b.SendAsync(It.IsAny<AgentMessage>()))
            .Callback<AgentMessage>(msg => capturedMessage = msg)
            .ReturnsAsync(true);

        await _orderAgent.ConfirmOrderAsync(order);

        Assert.NotNull(capturedMessage);
        Assert.Equal("BillingAgent", capturedMessage.TargetAgent);
        Assert.Equal(orderId, capturedMessage.Payload["orderId"]);
        Assert.Equal(1500m, capturedMessage.Payload["amount"]);
    }

    [Fact]
    public async Task BillingAgent_HandlesOrderConfirmationMessage()
    {
        var message = new AgentMessage
        {
            SourceAgent = "OrderAgent",
            TargetAgent = "BillingAgent",
            MessageType = "OrderConfirmed",
            Payload = new Dictionary<string, object>
            {
                { "orderId", "ORD-123" },
                { "amount", 1500m }
            }
        };

        var result = await _billingAgent.HandleMessageAsync(message);

        Assert.True(result.Success);
        Assert.Contains("invoice", result.Response.ToLower());
    }
}

This pattern verifies that agents send the right messages in the right format and that other agents can parse and respond to those messages correctly.

Layer 6: End-to-End Workflow Scenarios

After testing individual components, test full scenarios from start to finish. These tests use real or realistic data and verify the complete workflow.

public class EndToEndOrderProcessingTests : IAsyncLifetime
{
    private readonly WebApplicationFactory<Program> _factory;
    private HttpClient _client;
    private readonly string _testOrderId = "E2E-TEST-001";

    public EndToEndOrderProcessingTests()
    {
        _factory = new WebApplicationFactory<Program>();
    }

    public async Task InitializeAsync()
    {
        _client = _factory.CreateClient();
        await SeedTestDataAsync();
    }

    public async Task DisposeAsync()
    {
        _client?.Dispose();
        _factory?.Dispose();
        await CleanupTestDataAsync();
    }

    [Fact]
    public async Task CompleteOrderFlow_FromInitialRequestToConfirmation()
    {
        var request = new ProcessOrderRequest
        {
            OrderId = _testOrderId,
            UserId = "USER-001"
        };

        var response = await _client.PostAsJsonAsync("/api/orders/process", request);
        Assert.True(response.IsSuccessStatusCode);

        var result = await response.Content.ReadAsAsync<ProcessOrderResponse>();
        Assert.NotNull(result);
        Assert.Equal("Confirmed", result.Status);

        var orderDetails = await _client.GetAsync($"/api/orders/{_testOrderId}");
        var order = await orderDetails.Content.ReadAsAsync<Order>();
        Assert.Equal("Confirmed", order.Status);
        Assert.NotNull(order.ConfirmedAt);
    }

    private async Task SeedTestDataAsync()
    {
        var order = new Order
        {
            Id = _testOrderId,
            Status = "Pending",
            Total = 500m,
            Items = new List<OrderItem>
            {
                new OrderItem { Sku = "PROD-001", Quantity = 2, Price = 250m }
            }
        };

        var seedRequest = new { order };
        await _client.PostAsJsonAsync("/api/test/seed", seedRequest);
    }

    private async Task CleanupTestDataAsync()
    {
        await _client.DeleteAsync($"/api/test/cleanup/{_testOrderId}");
    }
}

End-to-end tests take longer to run than unit tests and can be more sensitive to environmental factors. Use them for the critical paths: the workflows that, if broken, cause real business impact.

Layer 7: Tool Output Quality Validation

Tools return data that agents consume. If a tool returns malformed or incomplete data, the agent might not recognize it or might misinterpret it. Validate tool output quality explicitly.

public class ToolOutputValidationTests
{
    private readonly ToolOutputValidator _validator;

    public ToolOutputValidationTests()
    {
        _validator = new ToolOutputValidator();
    }

    [Fact]
    public void ValidateCustomerData_WithCompleteData_Passes()
    {
        var output = new
        {
            customerId = "CUST-001",
            name = "Acme Corp",
            email = "contact@acme.com",
            status = "Active",
            createdAt = DateTime.UtcNow
        };

        var result = _validator.ValidateCustomerOutput(output);
        Assert.True(result.IsValid);
    }

    [Fact]
    public void ValidateCustomerData_WithMissingEmail_Fails()
    {
        var output = new
        {
            customerId = "CUST-001",
            name = "Acme Corp",
            status = "Active"
        };

        var result = _validator.ValidateCustomerOutput(output);
        Assert.False(result.IsValid);
        Assert.Contains("email", result.Errors);
    }

    [Fact]
    public void ValidateCustomerData_WithInvalidStatus_Fails()
    {
        var output = new
        {
            customerId = "CUST-001",
            name = "Acme Corp",
            email = "contact@acme.com",
            status = "Unknown",
            createdAt = DateTime.UtcNow
        };

        var result = _validator.ValidateCustomerOutput(output);
        Assert.False(result.IsValid);
        Assert.Contains("status", result.Errors);
    }
}

This catches cases where a tool works technically but returns data in an unexpected format or with missing fields. The agent might still accept it but then encounter problems downstream when it tries to use the data.

Putting It Together: A Testing Strategy

You don’t need all seven layers for every agent. Use this framework to decide what to test:

• Always use MCP Inspector during development. It’s fast feedback.
• Always write unit tests for tools. They’re quick and catch logic errors.
• Always test workflow state for agents with complex branching logic.
• Test missing-input handling if users provide unstructured requests.
• Test agent coordination if multiple agents work together.
• Use end-to-end tests for critical business workflows, not for every path.
• Validate tool output quality if tools are external or frequently change their responses.

Start with layers 1 and 2. They’re the fastest to write and catch the most common issues. Add other layers as your agent grows in complexity.

Testing in a CI/CD Pipeline

Once your tests are written, integrate them into your CI/CD pipeline. Run unit tests on every commit. Run workflow tests on every build. Run end-to-end tests before deploying to staging.

Here’s a simple Azure Pipelines configuration:

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: UseDotNet@2
    inputs:
      version: '8.x'

  - task: DotNetCoreCLI@2
    displayName: 'Restore NuGet packages'
    inputs:
      command: 'restore'
      projects: '**/*.csproj'

  - task: DotNetCoreCLI@2
    displayName: 'Run unit tests'
    inputs:
      command: 'test'
      projects: '**/*.Tests.csproj'
      arguments: '--configuration Release --logger trx --collect:"XPlat Code Coverage"'

  - task: DotNetCoreCLI@2
    displayName: 'Run workflow tests'
    inputs:
      command: 'test'
      projects: '**/*.WorkflowTests.csproj'
      arguments: '--configuration Release'

  - task: PublishCodeCoverageResults@1
    inputs:
      codeCoverageTool: Cobertura
      summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

This pipeline restores packages, runs unit tests with code coverage, and runs workflow tests. If any test fails, the build fails and the deployment is blocked. That’s the point: catch problems early, before they reach production.

Common Pitfalls and How to Avoid Them

Over-testing: Not every code path needs a test. Focus on the paths that matter: the ones that agents actually exercise and the ones where failures have real consequences.

Under-mocking: When you mock dependencies, mock them correctly. If your mock doesn’t behave like the real dependency, your test passes but production behaves differently. Make sure your mocks return realistic data and handle edge cases the same way the real service does.

Ignoring timeouts: Agents often have timeout limits on tool calls. Test that your tools respond fast enough. If a tool takes 10 seconds and the agent times out after 5, the agent will encounter problems in production even if the tool works fine in isolation.

Not testing error paths: Most tests focus on the happy path. Write tests for what happens when tools fail, when data is missing, when APIs are slow. These are the scenarios that matter most in production.

Flaky tests: Tests that sometimes pass and sometimes fail undermine confidence in the entire test suite. If a test is flaky, fix it or remove it. A reliable test that catches real issues is more valuable than ten flaky tests.

Moving Forward

Testing AI agents is still evolving. There’s no single standard yet, and every team finds patterns that work for their specific situation. The layers described here are a starting point. Use them, adapt them, and share what works for you.

The key principle is simple: test early, test often, and test the things that matter. Your agents will be more reliable, your deployments will be safer, and your team will have confidence that production has been tested thoroughly.

What is MCP and why do I need to test it?

MCP (Model Context Protocol) is the standard that defines how agents interact with tools. Testing MCP ensures that your tools are correctly defined, respond with the right data format, and behave predictably. If the MCP interface is broken, the agent cannot use the tool effectively, no matter how well the agent itself is built.

How do I test an agent that makes non-deterministic decisions?

Focus on testing the decision logic and the state transitions, not the exact model output. Mock tool responses and verify that the agent calls the right tools and makes the right branching decisions based on those responses. You’re testing the agent’s reasoning process, not the language model itself.

Should I test every possible input combination?

No. Use equivalence partitioning: group similar inputs together and test one representative from each group. Test the happy path, the error cases, boundary conditions, and missing data scenarios. You’ll catch most issues without testing every permutation.

How do I handle external dependencies in tests?

Mock them. Use a mocking library like Moq to create fake versions of external services that return controlled responses. This makes tests fast, reliable, and independent of external systems. Only use real external services in end-to-end tests that specifically verify integration.

What’s the difference between a workflow test and an end-to-end test?

A workflow test verifies that an agent calls tools in the right order and makes the right decisions, using mocked tool responses. An end-to-end test runs the complete flow with real or realistic data and verifies the final result. Workflow tests are faster and more focused; end-to-end tests are slower but catch integration issues.