.NETTestingReported by candidates

How do you unit test your .NET code? What do you test, and how is a test laid out?

Asked as "how would you test this?" and "your experience with unit testing" at Wipro (October 2026), TCS (August 2026), Codebase Solutions and Saviant.

Say this first · about 30 seconds

A unit test checks one small piece of logic on its own, fast, with no database or network. I use xUnit.
Each test follows Arrange, Act, Assert: set up the inputs, call the one method, check the result.
I test business rules and their edges, like the last free day of a grace period, and I use an xUnit Theory, one test run over several input rows, instead of copying tests.
Anything outside the class, like the database, the clock or an HTTP API, I pass in as a parameter or through the constructor, so the test can hand it fixed values. Integration tests then check the real pieces together.

Make it yours · UDC payoff quote tests (invented example)

Situation: at UDC Finance the early adds a break fee that depends on how many months are left. A refactor changed it, and nobody could say for sure the old answers still held.
What I did: before the refactor I wrote a [Theory] with ten real quotes from the old code as : months left in, fee out. Then I refactored until they all passed.
Result: the refactor shipped with no change in any quote, and the tests stayed as a safety net for the next change.
What I'd say: when I touch money logic I first write tests that record what the current code returns, then change the code until they still pass.

The code, simplified

Invented to show the shape, in C#. Tap Next to walk one row.

UDC.sln · where this file sits

Tests/

Diagram · step 1xUnit runs the test once per row. This row: 24 months left, 480 expected.

xUnit

Testone row

Calculatorrefactored

run(24, 480)

BreakFeeTests.cs · line 2 · 1 of 3One old quote: 24 months left, break fee 480.

Fix later in your repo The ten cases come from old quotes; a property-based test could try many more inputs.

Say it out loud, then check

Show the 30-second answer

A unit test checks one small piece of logic on its own, fast, with no database or network. I use xUnit.
Each test follows Arrange, Act, Assert: set up the inputs, call the one method, check the result.
I test business rules and their edges, like the last free day of a grace period, and I use an xUnit Theory, one test run over several input rows, instead of copying tests.
Anything outside the class, like the database, the clock or an HTTP API, I pass in as a parameter or through the constructor, so the test can hand it fixed values. Integration tests then check the real pieces together.

Check your answer: tick what you said

Unit test: one unit of logic, in memory, fast, repeatable. No database, network, file system or real clock.
Arrange, Act, Assert: set up, call one thing, check one behaviour. Name the test after the behaviour.
xUnit: [Fact] for one case, [Theory] with [InlineData] for the same rule over several inputs. A new class instance per test, so instance fields aren't shared (static fields still are).
Test the rules and the edges (boundaries, nulls, errors), not getters or the framework.
Dependencies (repository, clock, HTTP) come in through the constructor or a parameter, so a test can pass a fake. Mocking libraries like Moq help.
Unit tests vs integration tests: unit for logic, integration (, a real or container database) for wiring, SQL and HTTP.
A flaky test, one that passes or fails without a code change, usually hides time, shared state or order. Fix the cause, never retry until green.

You said 0 of 7

Then add your example: UDC payoff quote tests (invented example)

Situation: at UDC Finance the early adds a break fee that depends on how many months are left. A refactor changed it, and nobody could say for sure the old answers still held.
What I did: before the refactor I wrote a [Theory] with ten real quotes from the old code as : months left in, fee out. Then I refactored until they all passed.
Result: the refactor shipped with no change in any quote, and the tests stayed as a safety net for the next change.
What I'd say: when I touch money logic I first write tests that record what the current code returns, then change the code until they still pass.

See it

LateFeeCalculatorthe unit under test

manual check, 2 days before release edge cases: whoever remembered

1/6Before: the late-fee rule was checked by hand in a test environment, once per release.

In plain words

Words first. A unit test is a small method that calls one piece of your code with fixed inputs and checks the answer. xUnit is the most used .NET test library: you mark methods as tests and it runs them. The build (or pipeline) is the automatic run on every , a proposed code change, that compiles the code and runs all tests; a failing test blocks the change. An edge is the value where a rule changes, like day 10 versus day 11. A dependency is anything your class needs from outside: a database, the clock, another service. A fake (or mock) is a stand-in for one, used only in tests. DI (dependency injection) is ASP.NET Core passing the real ones in for you. A flaky test passes sometimes and fails other times with no code change. In the code, 800m is a decimal number (the m marks it; decimal adds money up exactly, with no rounding drift) and is a date with no time.
A unit test is a spot-check on a factory line. You take one part, test it on the bench with known inputs, and check it against the spec. You don't need the whole car to know the brake pad is the right thickness.
Arrange, Act, Assert is the recipe: put the part on the bench (arrange), do the one thing (act), measure (assert).
The bench must be the same every time. If a test depends on today's date, it's like measuring a part with a ruler that changes length by the day.

The senior answer · about 2 minutes

What I test

The business rules, because that's where bugs cost money: a late fee, a amount, an eligibility check. For each rule I test the normal case and the edges, like day 10 versus day 11 of a grace period, a minimum and a maximum.
I don't test what the framework already guarantees, like that a property returns what I set or that ASP.NET Core routes a request. Those tests break on every refactor and catch nothing.

How a test is written

Arrange, Act, Assert, with a blank line between them, and one behaviour per test. The name says the behaviour: No_fee_inside_grace_period, so a failure reads like a sentence in the build log.
When the same rule needs several inputs, an xUnit [Theory] with [InlineData] rows instead of five copied tests. xUnit builds a new test class for every test, so nothing leaks from one test into the next.
Anything I don't control, the database, an HTTP API, the clock, comes in from outside: through the constructor, which DI fills in the real app, or as a parameter. In the test I pass a fixed date or a fake repository. Since .NET 8 there's for the clock.

Where unit tests stop

Unit tests can't tell me the SQL is right or that the API is wired up. For that I write fewer, slower integration tests with and a real database in a container. Most tests are unit tests; a few are integration; a handful are end-to-end, driving the real Angular portal in a browser with Playwright.
In the pipeline every runs the tests, and a red test blocks the merge. A flaky test is a bug in the test or the code, so I find the cause rather than re-running until it's green.

All in one flow

Coming Not written yet: the card pass adds it.

The story

Before
BMW FS charges a late fee when an instalment is paid more than 10 days after its due date: 5% of the instalment, at least 25, at most 100. So day 10 is the last free day. For a long time the rule was checked by hand in the test environment before each release.
Why it had to change
A change to the grace period moved it by a day. The manual check tried a payment 20 days late, which was still right. Nobody tried day 10. Customers who paid on day 10 were charged a fee they didn't owe, and it was found from complaints.
How it works now
The rule now has unit tests. Each sets up its inputs, calls once and checks the answer: Arrange, Act, Assert. The date is an input, not the computer's clock, so the result is the same on every run. One test pins day 10 (no fee); a [Theory] runs day 11 with three amounts to hit the minimum, a normal fee and the maximum. The diagram walks one test.
What happens next
Every runs the tests in seconds, and a change that breaks day 10 fails the build before review.
What we gained
Edges are written down once and checked forever, the build log names the broken rule, and refactoring the calculator is safe. The try-first exercise shows the one thing that can still make a test lie.

In the lending API

One test per behaviour, laid out as Arrange, Act, Assert.

Only the key lines are shown; Deep walks the whole file.

Lending.sln · where this file sits

tests/Domain.Tests/

⋯ 2 lines in Deep⋯ 1 line in Deep⋯ 2 lines in Deep

LateFeeCalculatorTests.cs · line 8 · 1 of 4[Fact]: one test, one case.

The code, file by file

BMW FS late fees in the lending API: the rule, then its tests. Tap Next to walk the diagram with the code.

Lending.sln · where these 2 files sit

tests/Domain.Tests/
src/Domain/Fees/

Diagram · step 2Fees should start on day 11. A change started charging on day 10. Nobody checked day 10.

LateFeeCalculatorthe unit under test

manual check, 2 days before release edge cases: whoever remembered

LateFeeCalculatorTests.cs · line 1 · 1 of 12Without tests like these, the day-10 bug in the diagram reached customers. xUnit finds every public method marked as a test in this class and runs it.

What they ask next

The follow-ups interviews really ask. Answer out loud, then tap to check.

InterviewerUnit test vs integration test: what is the difference, and how many of each?
A unit test checks one class's logic in memory, with its dependencies replaced. An integration test runs real pieces together: the API through , with a real database in a container, so it catches wiring, SQL and serialization bugs. Unit tests are fast, so I write many; integration tests are slower, so I write fewer, one per important flow.
Microsoft Learn: integration tests in ASP.NET Core
ReportedHow do you test a class that uses a database or another service?
The class gets its dependency through the constructor as an , like . In the real app DI passes the real one; in the test I pass a fake that returns fixed data. A mocking library such as Moq builds that fake: says "when GetAsync(42) is called, return this contract", and .Object is the fake you pass to the class. The SQL itself I test in an integration test, not with a mock.
```
var repo = new Mock<IContractRepository>();
repo.Setup(r => r.GetAsync(42))
  .ReturnsAsync(contract);
var svc = new PayoffService(repo.Object);
```
Codebase Solutions: how would you test a program?

Follow-up tree

Answer, then open the next level. That is the order an interviewer digs in.

Reporteda candidate was asked Intervieweran interviewer asks it

InterviewerUnit test vs integration test: what is the difference, and how many of each?
A unit test checks one class's logic in memory, with its dependencies replaced. An integration test runs real pieces together: the API through , with a real database in a container, so it catches wiring, SQL and serialization bugs. Unit tests are fast, so I write many; integration tests are slower, so I write fewer, one per important flow.
Microsoft Learn: integration tests in ASP.NET Core
ReportedHow do you test a class that uses a database or another service?
The class gets its dependency through the constructor as an , like . In the real app DI passes the real one; in the test I pass a fake that returns fixed data. A mocking library such as Moq builds that fake: says "when GetAsync(42) is called, return this contract", and .Object is the fake you pass to the class. The SQL itself I test in an integration test, not with a mock.
```
var repo = new Mock<IContractRepository>();
repo.Setup(r => r.GetAsync(42))
  .ReturnsAsync(contract);
var svc = new PayoffService(repo.Object);
```
Codebase Solutions: how would you test a program?
ReportedHow do you test a feature after you've built it?
In layers. Unit tests for its rules and edges, written with the code. An integration test for the main flow through the API and the database. Then I run it myself in the test environment with real-looking data, trying the odd cases a user would hit, before QA and . And every bug found later gets a regression test first, so it can't come back.
Saviant: how do you test features after implementation?
ReportedWhat code coverage do you aim for?
Coverage shows which lines ran during tests, not whether they were checked. Teams often set a gate, say 80% on new code in SonarQube, and that's a useful floor. But I'd rather have 70% that tests the rules and edges than 95% made of tests that assert nothing. High coverage of a rule with no assert about day 10 would still have shipped our bug.
Asked with unit testing (Deloitte, Wipro, 2026)
xUnit vs NUnit vs MSTest?
All three do the job. xUnit is what most new .NET projects use, and the ASP.NET Core team uses it: [Fact] and [Theory], a new class instance per test, setup in the constructor. NUnit uses [Test] and [TestCase] with [SetUp] methods. MSTest is Microsoft's own, [TestMethod]. I'd follow whatever the team already has.

Production bugs, and how to tell them

Each one: what you see, why, the fix in code, and the line to say.

Try first: why does this test fail only from the 1st to the 11th?
```
Azure DevOps pipeline, LendingApi PR builds:
1st-11th of every month: FAILED  Fee_charged_after_grace_period
12th-31st: PASSED
No code change between the runs.

Read the Before code and find the cause before you open the answer.
```
Cause
The calculator read the date itself with . The test made the due date the 1st of the current month and expected a fee. Run on the 15th, the payment is 14 days late: fee, test passes. Run on the 5th, it's only 4 days late: no fee, test fails. The test depends on the day it runs: it's flaky.
Fix
Pass the date in. takes today as a parameter (or a in a service), and the test sets both dates itself. Now the result depends only on the inputs, and the test is the same on any day.
Before · LateFeeCalculator.cs · line 5 · 1 of 1Reads the real clock inside the class. The test can't control it.
Say it
The test was flaky because the class read the real clock, so the outcome depended on the calendar. We made the date an input: a parameter here, TimeProvider in services. The test fixes both dates and passes every day. My rule: a unit test controls every input, and time is an input.

Production incident

Not on this card A basic concept card: its production story is the try-first flaky test and the day-10 fee bug in the story.

Traps

Don't say~~One test per method.~~SayOne test per behaviour: a method with a rule and three edges gets several tests, or one Theory.
Don't say~~Mock everything, including the database query.~~SayPut outside dependencies (database, HTTP) behind your own interface and fake that in unit tests; test the real SQL in an integration test.
Don't say~~A flaky test: just re-run the pipeline.~~SayFlaky means something uncontrolled, usually time, shared state or order. Find it and remove it.

Traps

What should you say instead? Tap to check.

Don't sayOne test per method.
Say instead
One test per behaviour: a method with a rule and three edges gets several tests, or one Theory.
Don't sayMock everything, including the database query.
Say instead
Put outside dependencies (database, HTTP) behind your own interface and fake that in unit tests; test the real SQL in an integration test.
Don't sayA flaky test: just re-run the pipeline.
Say instead
Flaky means something uncontrolled, usually time, shared state or order. Find it and remove it.

Live coding

Easy first, then harder. Set a timer and type it before you look.

Task 1

Question index: Musteasy · 15 minutes

Write xUnit tests for a late-fee rule: no fee up to 10 days late, then 5% of the instalment, at least 25 and at most 100. Cover the edges.

Question index (Must): write xUnit tests for a LoanService method, AAA and Theory

Stuck? Hints

Which days matter most? Look at where the rule changes.
How do you test 25, 40 and 100 without three copies of the same test?
Where does today's date come from in your test?

Show a solution

Lending.sln · where this file sits

terminal · line 5 · 1 of 1The Fact and the three InlineData rows: four tests.

What the interviewer checks

Day 10 (no fee) and day 11 (fee) are both tested.
Minimum and maximum hit, plus one normal value.
[Theory] with [InlineData] for the amounts.
Fixed dates; nothing reads the real clock.
Arrange, Act, Assert, names that describe the behaviour.
Senior extra: says what an integration test would add.

With AI tools

AI assistants write unit tests quickly, and interviewers now ask how you check them. The common problems: tests that assert only , tests that check the mock returned what the test told it to return, and missing edges like day 10. I use Copilot to draft the test list and the boilerplate, then I add the boundary rows myself and make sure each test fails if I break the rule.

Glossary: every name, one line each →

My notes

Paste the NOTES block from your doubt chat here. The grader never reads notes; the coach reads "Still unclear".

Unit testing C# with xUnit (Microsoft Learn)Unit testing best practices (Microsoft Learn)Integration tests in ASP.NET Core TimeProvider (Microsoft Learn)

Where it was asked

Codebase Solutions: how would you test a program?Saviant: how do you test features after implementation?Wipro: full stack questions, unit testing (2026)