yoklainterview sim
ProgressHistory

Backend Csharp Testing Tooling Interview Questions

75 verified Backend Csharp Testing Tooling interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Csharp Testing ToolingDifficulty 1
In xUnit, what determines whether a method is discovered and run as a test?
  • aThe method name must start with Test, since xUnit still relies on naming conventions for discovery, much like some legacy test frameworks required
  • bThe method must be decorated with [Fact] (or [Theory]), which xUnit's discovery mechanism scans for✓
  • cThe method must be public static void so the test runner can call it without creating an instance
  • dThe containing class must implement ITestCase, an interface xUnit's runner looks for at startup
Explanation:xUnit discovers tests purely through attributes: [Fact] for a test with no parameters, [Theory] for a data-driven test. There is no naming-convention requirement, no static requirement (xUnit creates an instance per test), and no ITestCase interface to implement.
Csharp Testing ToolingDifficulty 1
What is the key difference between [Fact] and [Theory] in xUnit?
  • a[Fact] marks a test that takes no parameters and runs once; [Theory] marks a test that takes parameters and needs a data source such as [InlineData] to supply values✓
  • b[Fact] is for synchronous tests and [Theory] is for async Task tests, so mixing the two attributes within the same test class requires separate assertion libraries and separate test runner configuration
  • c[Theory] is simply a deprecated alias for [Fact] kept for backward compatibility with older test runners
  • d[Fact] runs before all [Theory] tests in the class, acting as a setup step for the data-driven tests
Explanation:[Fact] is for a single, parameterless test case. [Theory] is for a data-driven test method that takes parameters, and it requires at least one data source attribute ([InlineData], [MemberData], or [ClassData]) supplying the argument values for one or more runs. Neither attribute is about sync vs async, and there's no implicit ordering between them.
Csharp Testing ToolingDifficulty 2
[Fact]
public void ChecksTotal()
{
    int actualTotal = ComputeTotal(); // returns 7
    Assert.Equal(actualTotal, 10);
}

The test fails. What does the failure message report?
  • a"Expected: 7, Actual: 10" — because the first argument to Assert.Equal is treated as expected, and here actualTotal (7) was passed first by mistake✓
  • b"Expected: 10, Actual: 7" — because xUnit always labels the smaller numeric value as the actual result, inferring intent from the values rather than argument position
  • cA compile error, because Assert.Equal requires the literal expected value to be passed as the second argument
  • d"Expected: 10, Actual: 10" — because xUnit resolves both arguments to the same comparison target before reporting them
Explanation:Assert.Equal(expected, actual) treats its first argument as "expected" and its second as "actual", purely by position. Here the call is Assert.Equal(actualTotal, 10), so xUnit reports actualTotal (7) as expected and 10 as actual. This is a common junior mistake — the arguments are swapped, which doesn't change whether the test passes or fails but does produce a misleading message.
Csharp Testing ToolingDifficulty 2
public class MathTests
{
    [Theory]
    [InlineData(2, 4)]
    [InlineData(3, 9)]
    public void SquaresNumber(int input, int expected)
    {
        Assert.Equal(expected, input * input);
    }
}

How many times does SquaresNumber execute, and what does each [InlineData] provide?
  • aIt executes once, receiving both [InlineData] rows merged into a single array parameter
  • bIt executes 4 times, because two [InlineData] attributes combined with two method parameters multiply together to produce four separate runs of the method body
  • cIt executes 2 times, once per [InlineData] row, with input/expected bound to that row's values each time✓
  • dIt does not compile, because [Theory] methods may only have a single [InlineData] attribute
Explanation:Each [InlineData(...)] attribute supplies one full set of arguments for one execution of the [Theory] method. With two [InlineData] attributes, the method runs twice: once with input=2, expected=4, once with input=3, expected=9. A [Theory] method can have any number of [InlineData] attributes stacked on it.
Csharp Testing ToolingDifficulty 1
Why is "test isolation" (each test being independent of the others) considered a core testing principle?
  • aIsolation is mainly a performance optimization — isolated tests simply run faster because the runtime can skip class loading and assembly resolution between each individual test method
  • bIsolation means every test must use a real database and real network calls instead of mocks, to prove the whole system works together
  • cIsolation is only relevant for integration tests; unit tests are exempt from this principle because they never touch shared resources
  • dAn isolated test's outcome depends only on its own setup and the code under test, so it can be run alone, in any order, or in parallel and still give a reliable result✓
Explanation:Test isolation means a test's result doesn't depend on execution order, on other tests having run first, or on leftover shared state. This matters because test runners are free to run tests in any order (and often in parallel); if tests share mutable state without resetting it, results become order-dependent and flaky. It has nothing to do with whether mocks are used, and it applies to unit tests just as much as integration tests.
Csharp Testing ToolingDifficulty 2
public class CounterTests
{
    private int _count;

    public CounterTests()
    {
        _count = 10;
    }

    [Fact]
    public void FirstIncrements()
    {
        _count++;
        Assert.Equal(11, _count);
    }

    [Fact]
    public void SecondStartsFresh()
    {
        Assert.Equal(10, _count);
    }
}

Both tests pass when run together. Why doesn't FirstIncrements leaving _count = 11 affect SecondStartsFresh?
  • aIt's a coincidence of execution order — if SecondStartsFresh happened to run right after FirstIncrements within the very same test process without any restart, it would see 11 instead
  • bxUnit creates a brand-new instance of CounterTests for each [Fact] method, so the constructor runs again and _count starts fresh at 10 for SecondStartsFresh✓
  • cThe test runner resets every instance field to its declared default before each [Fact], even on the same object, overriding whatever the constructor set
  • dSecondStartsFresh only passes because Assert.Equal(10, _count) reads a cached snapshot taken before FirstIncrements ran, not the live field value
Explanation:xUnit constructs a new instance of the test class for every [Fact]/[Theory] method — the constructor acts as per-test setup, replacing [SetUp]/[BeforeEach] from other frameworks. FirstIncrements and SecondStartsFresh therefore run on two separate CounterTests objects, each getting its own fresh constructor call (_count = 10). Mutating _count in one instance has no effect on the other instance's field.

By specialization

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3300-question Backend bank.

Start interview