An integration test should state which application boundary it exercises. WebApplicationFactory can run an ASP.NET Core application in a test host and provide an HTTP client. It does not automatically prove that a production database, identity provider or reverse proxy works.

This .NET Core interview exercise deliberately replaces a repository. The test checks routing, dependency injection, response serialization and application behavior. Its fake repository is a controlled input, not evidence of database compatibility.

What does the sample application expose?

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSingleton<IArticleRepository, EmptyArticles>();
var app = builder.Build();
app.MapGet("/articles/{id}", (string id, IArticleRepository repository) =>
    repository.Find(id) is { } article
        ? Results.Ok(article) : Results.NotFound());
app.Run();

public partial class Program { }
public record Article(string Id, string Title);
public interface IArticleRepository { Article? Find(string id); }
public sealed class EmptyArticles : IArticleRepository
{
    public Article? Find(string id) => null;
}

Make a separate xUnit test project that references this web project and Microsoft.AspNetCore.Mvc.Testing with a compatible .NET 10 version. Include Microsoft.Extensions.DependencyInjection.Extensions for RemoveAll.

How does the test replace the dependency?

using System.Net;
using Microsoft.AspNetCore.Mvc.Testing;
using Microsoft.AspNetCore.TestHost;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection.Extensions;
using Xunit;

public sealed class ArticleTests
{
    [Fact]
    public async Task Unknown_article_is_not_found()
    {
        await using var factory = new WebApplicationFactory<Program>()
            .WithWebHostBuilder(builder => builder.ConfigureTestServices(services =>
            {
                services.RemoveAll<IArticleRepository>();
                services.AddSingleton<IArticleRepository, EmptyArticles>();
            }));
        using var client = factory.CreateClient();
        using var response = await client.GetAsync("/articles/missing");
        Assert.Equal(HttpStatusCode.NotFound, response.StatusCode);
    }
}

The replacement is intentionally empty here. Extend it with a known article to test success and JSON fields. If the repository is asynchronous in the real application, preserve that real interface instead of changing production code to fit this small example.

What about authentication?

This sample endpoint is public. For protected routes, use a clearly named test authentication handler with controlled claims. Keep separate tests for anonymous rejection, authenticated denial and allowed access. Do not disable authorization globally and then claim permission coverage.

A fake authentication scheme does not test token validation by the real provider. That requires its own appropriate boundary and environment. Explain that limitation in the test report.

How should data remain isolated?

A stateful fake shared across tests can make outcomes depend on execution order. Give each test independent state or an explicit reset strategy. Real database integration tests need a dedicated disposable database and safe cleanup, never a production connection copied into test settings.

Check startup configuration too. A factory can still run hosted services or initialize real clients if the test does not replace them. Review application composition before issuing a request.

Which failures deserve separate tests?

  • Known and unknown records.
  • Invalid input before repository work.
  • A controlled dependency failure and its safe response.
  • Permission boundaries for protected routes.
  • Cancellation behavior where the application supports it.

Assert the status and meaningful response fields. Avoid asserting entire serialized documents when ordering or unrelated metadata is not part of the contract.

A useful interview answer

“This test runs the application through HTTP with a fake repository. It checks application wiring and response behavior. I would add separate real-database and deployment checks for the boundaries it deliberately replaces.” That is a stronger claim because its evidence is precise.

References and next practice

learn.microsoft.com — net tests

dotnet question collection · Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud