What is a static class in C#? Explain what it can contain, how it differs from a singleton, where extension methods and C# 14 extension members live, static state and thread-safety, and why heavy use of static classes hurts testability.

How I would answer this in an interview

A static class is a class that can't be instantiated or inherited and may contain only static members. It's a container for stateless helpers, constants, extension methods and factories. I'd cover what it can contain, how it differs from a singleton, where extension methods and C# 14 extension members live, static state and thread safety, and why heavy static use hurts testability.

1. What a static class can contain

public static class GstCalculator
{
    public const decimal Rate = 0.10m;                          // constant
    private static readonly FrozenSet<string> Exempt = ...;     // static readonly data

    static GstCalculator() { }                                  // optional static constructor

    public static decimal Gst(decimal amount) => Math.Round(amount * Rate, 2, MidpointRounding.AwayFromZero);
    public static bool IsExempt(string category) => Exempt.Contains(category);
}

• Only static members: methods, properties, fields, events, constants, nested types, a static constructor.
• No instance constructors, no instance members, can't be used as a type argument, variable type or base class.
• The compiler marks it abstract sealed in IL.

2. Static class vs singleton

In modern .NET, a "singleton" should almost always be a DI-registered singleton (services.AddSingleton<IRateCache, RateCache>()) rather than the classic Instance static property — you get the single instance without global access, and tests can substitute it.

3. Extension methods and C# 14 extension members

Extension methods must be declared in a non-generic, non-nested static class:

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddOrdering(this IServiceCollection services, IConfiguration config) { ... }
}

C# 14's extension blocks also live inside static classes, and add extension properties, static extension members and operators:

public static class StringExtensions
{
    extension(string? value)
    {
        public bool IsBlank => string.IsNullOrWhiteSpace(value);
    }
}

The static class is just the container; callers use the members as if they were on the target type.

4. Static state and thread safety

Static fields are shared by every thread and every request for the life of the process:

• Mutable static state (static List<T>, static Dictionary<,>) is a race condition waiting to happen and can leak data between users/tenants.
• Static references are GC roots — anything stored there is never collected (classic static cache memory leak).
• Static initialisation is thread-safe (the runtime runs the static constructor once under a lock), but subsequent reads/writes are not.
• If you need static state: make it immutable (static readonly FrozenDictionary), or thread-safe (ConcurrentDictionary, Interlocked), and bounded.

5. Why heavy static use hurts testability

• Can't substitute: code calling PricingRules.Calculate(...) or DateTime.UtcNow is hard-wired; tests can't control behaviour.
• Hidden dependencies: a static method that reads configuration, the database or the clock hides those dependencies from the constructor.
• Shared state between tests: static state set by one test leaks into others, causing order-dependent flaky tests (especially when xUnit runs test classes in parallel).
• Configuration: statics initialised from config can't vary per test or per tenant.

Pure, deterministic functions (maths, formatting, mapping without I/O) are perfect as statics — they're easy to test directly. The problem is statics with I/O, time, configuration or mutable state.

6. A production example

A multi-tenant API cached tenant settings in static Dictionary<string, TenantSettings> Cache inside a static SettingsHelper. Under concurrent load it threw intermittent InvalidOperationExceptions (concurrent modification) and once returned another tenant's settings because of a race in a check-then-add. Tests were flaky because the cache persisted between tests. We replaced it with a DI singleton ITenantSettingsProvider backed by IMemoryCache, injected where needed; tests used a fake provider and the races disappeared.