单元测试中，static readonly对比const存储测试假数据有无明显优势？

Great question—since we’re talking unit test fake data, let’s cut through the general static readonly vs const debate and focus on what actually matters for your test suite and team consistency.

When to Use const #

const only works for compile-time constant literals—think hardcoded strings, integers, or enums that will never need runtime calculation. For example:

const string TestUserEmail = "test@example.com";
const int ExpectedSuccessStatusCode = 200;

Its only real "advantage" here is minor syntax brevity, and it’s baked into the compiled code (though performance gains are negligible in unit tests). The big catch: you can’t use const for anything that needs to be initialized at runtime—like DateTime values, GUIDs, or complex test objects.

When to Use static readonly #

This is where static readonly shines for unit tests. It’s initialized at runtime, so it handles all the fake data scenarios const can’t, plus all the ones it can:

• Runtime-calculated values: static readonly DateTime TestStartDate = new DateTime(2024, 1, 1);
• Reusable complex objects: static readonly TestProduct SampleProduct = new TestProduct { Id = 1, Price = 9.99m };
• Values that might need adjustment later (without forcing a full recompile of every dependent file, though this is less critical for test projects).

Even for simple literals, static readonly is safer because it gives you flexibility to expand or modify the fake data later without rewriting the declaration.

Team Recommendation for Your规范 #

Default to static readonly for all unit test fake data. Here’s why:

• It covers 100% of your fake data use cases, from simple strings to complex test objects.
• It avoids the frustration of having to refactor a const to static readonly later when you need runtime logic.
• The syntax difference is minimal, and consistency across your test suite is more important than minor brevity.

Only use const if the fake data is a permanent, unchanging compile-time literal (e.g., a fixed test tag like const string UnitTestMarker = "UT") and the team explicitly agrees it will never need to evolve.

内容的提问来源于stack exchange，提问作者Sam Schneider