0

There have been many, many answers to the question about differences between static readonly and const. I am not asking about that. What I want to know is whether one or the other has a clear advantage when creating dummy data for a unit test class.

Here's an example with const:

[TestClass]
public class CustomerModelTest
{
   private const string firstName = "Bill";
   private const string lastName = "The Tester";

   // Test methods in the class then use the above data in their tests.
}

Here's the same example with static readonly:

[TestClass]
public class CustomerModelTest
{
   private static readonly string firstName = "Bill";
   private static readonly string lastName = "The Tester";

   // Test methods in the class then use the above data in their tests.
}

My team is in a debate over this question and I'd like to create a standard that would allow us to tell new hires, "Use [const/static readonly] as a default for holding dummy data, unless you have a good reason not to."

Here's what I understand so far:

So are there any fact-based reasons why one is preferable to the other in this situation? Or should our team just create an arbitrary standard?

Sam Schneider
  • 202
  • 4
  • 12
  • 4
    Option three: don't use either. Spell out the values you use in each test so it's self-contained and you're certain there are no hidden dependencies between tests (and then `const` is your only option since `readonly` doesn't work for locals). Use factory methods for complex objects and boilerplate code that's not appropriate to repeat. – Jeroen Mostert Feb 21 '18 at 16:15
  • @JeroenMostert that's a great point. I'm working with a pre-existing code base that already uses the pattern I showed above, but sounds like I should look at refactoring in the future. – Sam Schneider Feb 21 '18 at 18:00

2 Answers2

2

const is theoretically faster.

You are not going to notice this on the scale of the test runner starting up, loading your assembly and instantiating classes and invoking test methods through reflection.

static readonly keeps me from having to recompile any dlls that reference the current assembly.

But they're private, so this is irrelevant.

const cannot be used for computed values.

Which you don't seem to use.

So flip a coin and decide already, it doesn't really matter anyway.

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
1

As CodeCaster so expertly points out, you're not going to see any performance-related differences between the two.

And as Jaroen points out, you may be taking the wrong approach by defining constant-ish values at the class level in the first place. Maybe you should be using something like AutoFixture to define the values that don't matter, [TestCase]-style attributes and locally-defined variables/constants to define the ones that do.

If you do have a need to use constant-like values as fields, at some point you're bound to run into a need to use a computed value in a unit test (a DateTime, e.g.). So if consistency is your top priority then static readonly would be my vote.

StriplingWarrior
  • 151,543
  • 27
  • 246
  • 315
  • So it sounds like if I do stick with using class fields, there's no clearly superior choice, but I agree that from a personal preference stance I like the consistency of `static readonly`. – Sam Schneider Feb 21 '18 at 17:57