Accessing private fields

Question

First I'm sorry if question is already been asked but I don't find anyone like the mine (but I assume it is a pretty common question) So I'm trying to do some unit tests, and the first one is already problematic..

I have to test the constructor of my class, in the constructor I set an instance of a private field.. So how do I test if this PRIVATE field is not null? (because I assume is that what I have to test)--> To test :

 public BUDGET_MANAGER()
    {
        this.budget_provider = new BUDGET_PROVIDER();
    }

--> Test Mehod :

    [TestMethod()]
    public void BUDGET_MANAGERConstructorTest1()
    {
        BUDGET_MANAGER target = new BUDGET_MANAGER();      
        Assert.IsNotNull(??,"the provider is not instancied");

    }

How Can I do that? Thanks for help, I'm pretty lost in unit testing..

See: http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx (though you'd have to make the field `internal` instead of `private` which may not be what you're after.) — Kirk Woll, Feb 25 '11 at 22:31
possible duplicate of [Unit testing and checking private variable value](http://stackoverflow.com/questions/1093020/unit-testing-and-checking-private-variable-value) — Doc Brown, Feb 25 '11 at 22:33

score 4 · Accepted Answer · answered Feb 25 '11 at 22:31

4

In your unit testing you really shouldn't have to test anything that's private to a class. The private, internally-only known members are part of the implementation of the class and not part of its exposed (and tested) functionality.

Basically, think of the externally-visible members of the class as its "contract." That defines its actual type, what everything else sees. And that is the functionality being tested. Internal (private) members aren't known outside of the class for very good reason, a different class can implement that same "contract" (or interface) in a different way, with different private members.

What you're testing is the visible functionality, the contract or interface.

answered Feb 25 '11 at 22:31

David

208,112
36
198
279

Ok so nothing to test in my case? – bAN Feb 25 '11 at 22:35
@bAN: Depends on the class. If the "type" (interface, implied or explicit) is tightly coupled with the "class" (implementation) then the unit tests are indicating that some re-thinking and possible re-factoring may be in order. Separate the concepts of the interface from the class and the testing will become more obvious. (Incidentally, this is a positive test result... determining information about the class that may need to be changed.) To answer, though, yes there is nothing to test regarding the private member. Only public functionality. – David Feb 25 '11 at 22:38

Mark Byers · Answer 2 · 2011-02-25T22:37:56.127

Unit tests should not inspect private data. They should be testing that the behaviour defined by the interface of your class works, independent of any implementation details.

A typical test would call the constructor, and then afterwards call a public property or method and check that the result is as expected. Testing in this way means that if you later change your implementation to (for example) lazily construct a BudgetProvider only when it is needed, then all your tests will still work. Implementation details such as when a private member is or is not null is not relevant to clients of your class and therefore there is no need to test it in your unit tests.

I think you mean unit tests should *not* inspect private data, no? if so, agreed. — Paul, Feb 25 '11 at 22:30

score 1 · Answer 3 · answered Feb 25 '11 at 22:31

If your using mstest, right click the original class and press create test accessor, select your test project. Then test this condition using the accessor (should show up in intellisense).

I'm not sure its a very good idea though, as the other posters have said. You would be making the implementation more difficult to change.

score 1 · Answer 4 · answered Feb 25 '11 at 22:34

1

You should't really test any private variables of your classes.

Why would you like to test the constructor itself? It would make sense to test it if there is some logic. For example - you only construct the object if the given parameters are correct and you do validation before you create the object. Otherwise, construct the object and verify that it behaves as expected. Presumably if the constructor works incorrectly the object's behaviour will be incorrect as well.

Also resist the temptation of exposing private fields as properties just to validate that they were set correctly in the constructor.

answered Feb 25 '11 at 22:34

mfloryan

7,667
4
31
44

Ok thanks and in the case of setting a value (constructor parameter) to the private budget_provider in this constructor, do I mock the budget_provider to test if a set is called on the budget_provider? – bAN Feb 25 '11 at 22:42
Yes. That is a very good approach - you test interactions of your class with its dependencies (budget_provider). You can check if the expected interaction occur depending on the state of the object. – mfloryan Feb 26 '11 at 11:57

Xaqron · Answer 5 · 2011-02-26T15:16:05.023

0

Other guys mentioned what you should not to do when using unit testing.

I'll try to find a way to do what you want (you still need to test your constructor):

public BUDGET_MANAGER()
{
    try
    {
        this.budget_provider = new BUDGET_PROVIDER();
    }
    catch {}

    if (this.budget_provider == null)
        throw new NullReferenceException("Budget provider is null !");
}

edited Feb 26 '11 at 15:16

answered Feb 25 '11 at 22:51

Xaqron

29,931
42
140
205

No offense, but this is ridiculous. Unless the CLR is corrupted, "new" cannot return null. Case in point: write me a test that demonstrates this exception being thrown. – bryanbcook Feb 26 '11 at 13:35
You should consider code blocks as `pseudo-code` by default. As you see, the original question also has the same problem but we assume that he has briefed the case for readability. I added a `try/catch` over `new` keyword if it makes you happy. – Xaqron Feb 26 '11 at 15:22

Accessing private fields

5 Answers5

Linked