0

I understand that, when running unit tests, the class is instantiated for each test method. Therefore, I see no difference in initialising members upon declaration versus in the TestInitialize method. Is there anything particularly wrong about doing the former?

Note that this is a different question to TestInitialize vs ClassInitialize, although it technically might be similar.

Neo
  • 4,145
  • 6
  • 53
  • 76
  • 1
    Possible duplicate of [TestInitialize vs ClassInitialize](https://stackoverflow.com/questions/22999816/testinitialize-vs-classinitialize) – Sinatr Oct 27 '17 at 13:11
  • Depends if you need to re-initialise those values or set them up only one time. – Ric Oct 27 '17 at 14:16
  • @Sinatr Not quite. But it was because of that question I asked this one. I mean, what's the point of **ClassInitialize** if the class is instantiated for each test anyway? – Neo Oct 27 '17 at 14:31
  • @Ric Does that even matter for the purpose of this question? They could be reassigned whether initialised upon declaration or in **TestInitialize**. Of course, at declaration, you have the added option of making it **readonly** to prevent reassignment. – Neo Oct 27 '17 at 14:31
  • Its upto you how you want to organise your test class. Personally, if I define a member that gets used in every method, I tend to only reassign it in `TestInitialze` so I know that each method is getting the same default value, however it is changed hence `readonly` may not be suitable. – Ric Oct 27 '17 at 14:36
  • @Ric I think you're misunderstanding how unit tests are run, and therefore my question. I did mention it in my question, though - "the class is instantiated for each test method." Therefore, each test gets the same initialised value whether it was initialised upon declaration or in **TestInitialize**, even if a test reassigns it. I mentioned **readonly** for the 'upon declaration' case because this would protect against reassignment _within_ a test, but not for the purpose of protecting tests from each other (for the aforementioned reasons). – Neo Oct 27 '17 at 15:06
  • @Ric Try declaring a member `int x = 0` and put `Assert.IsTrue(++x == 0)` in each test. They'll all succeed. – Neo Oct 27 '17 at 15:21
  • Nope both (two tests) fail. – Ric Oct 27 '17 at 15:28
  • @Ric The fact they _both_ fail should have told you something. That was a typo by me, and the test was failing for a different reason to what we're discussing. Now if you change it to post-increment (i.e., `Assert.IsTrue(x++ == 0)`), or just change the `0` to `1`, you'll find they both succeed now. – Neo Oct 30 '17 at 09:53

1 Answers1

1

No, there is nothing wrong with initializing members in the declaration.

Primarily it comes down to preferred style. I prefer to make as many members readonly as I can, so I prefer initializing in the declaration when possible.

Others may prefer use of setup/teardown methods for all initialization and cleanup logic.

Eric Olsson
  • 4,805
  • 32
  • 35
  • Exactly. By initialising upon declaration, they can be made **readonly** which I also prefer (and is more defensive). – Neo Oct 27 '17 at 14:27