Unit Testing (xUnit/NUnit)
AAA pattern, mocking, Fact vs Theory, test doubles.
Arrange-Act-Assert (AAA) — the standard structure for a readable unit test: set up state and dependencies, invoke the thing under test once, assert the outcome.
xUnit specifics: [Fact] for a single test case, [Theory] + [InlineData(...)]/[MemberData(...)]
for the same test logic run across multiple inputs — directly useful for testing something like the
Strategy-pattern discount calculation across every customer type in one parametrized test instead of
one method per case.
Test doubles — know the vocabulary even if colloquially everyone says "mock" for all of them:
- Stub: returns canned data, no behavior verification.
- Mock: you assert specific calls were made on it (Verify in Moq/NSubstitute).
- Fake: a working lightweight implementation (e.g. in-memory repository instead of a real DB).
Good unit tests for the kind of code in this interview (services with injected interfaces) mock the interfaces, not concrete classes — which is exactly why DI-friendly, interface-based design (Strategy, Repository, etc.) is what makes code "testable" in the first place. That link is worth saying out loud if asked "why do SOLID/patterns matter" — testability is the concrete payoff.