Mocking private members

[dotnetprogrammer2008 dotnetprogrammer2008]

I am using Rhinomocks framework for unit testing. I have difficulty
mocking private members due to its protection level.
How to stub or mock private member?
How to stub or mock readonly properties?
Below is the class with readonly property and private member

public class DAL
{
public int TotalStudents
{
get
{
//Call database
return totalStudents;
}
}
private int NumberOfChoclatesToEachStudent;
public int calculateTotalChoclates()
{
return TotalStudents*NumberOfChoclatesToEachStudent;
}
}


Thank You

[Patrick Steele]

You usually don't mock/stub private methods. They're private because
they're NOT supposed to be accessible to outsiders -- even the unit
tests. You just want to test the interface to your class.

Suppose you have a class that calculates the area of a rectangle
(length * width). Your method signature probably looks like this:

public int CalculateArea(int width, int length)

Now, how that is implemented inside the method (including any private
methods it may call) are of no concern to your unit test. You just
want to write some unit tests so that if 5 and 8 are passed in, the
result is 40.

Remember, unit tests are used to test the behavior of a class, not the
implementation. If you test for implementation details, then changing
the implementation (like calling a web service to calculate the area)
will break your unit tests.

---
Patrick Steele
http://weblogs.asp.net/psteele

On Sun, Jan 9, 2011 at 1:04 AM, dotnetprogrammer2008

> --
> You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group.
> To post to this group, send email to rhino...@googlegroups.com.
> To unsubscribe from this group, send email to rhinomocks+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=en.
>
>

[bill richards]

You can generate a report which will let you know how much of your
code is covered by your unit tests, using a tool such as nCover in
conjunction with nUnit, for example will give you this ability.

What is the point in this? Well for one the generated report will let
you know just HOW MUCH of your code is tested, it will tell you if
your unit testing has covered all eventualities (i.e. execution
paths).

The ONLY way that I know of for getting 100% code coverage with my
unit tests is to develop TEST FIRST.

Retro fitting unit tests is bad/good ... good because you've at last
gotten around to testing your code, but bad because you generally end
up testing what has been written instead of testing that the
requirements have been met.

Step one ... delete your implementation

YOU : But I've spent so long on it already
ME : But is it tested?
YOU : No
ME : So how do you know it works?
YOU : I just know that what I've done is good prep work
ME : But is it tested?
YOU : No
ME : So how do you know it works?
YOU : It's hours of work
ME : But is it tested?
YOU : No

... you get the general idea.

Step two ... write your test
YOU : But I've not got anything to test yet
ME : Exactly
YOU : So what am I testing?
ME : The code you are about to write
YOU : But how can I test something I've not yet written?
ME : You can't
YOU : So shouldn't I write my code first?
ME : No, by writing your tests first, you are making conscious
decisions about HOW YOUR CODE WILL BE USED. You will know exactly what
you expect as inputs, and you will know exactly what you expect as
outputs, but YOU WON'T CARE ABOUT THE IMPLEMENTATION

public class MyExampleTestFixture
{
public void MyExampleTestMethod()
{
// Arrange
const int expected = 1;
IMyInterface x = new MyInterfaceImplementation();

// Act
x.IncrementCounter();

// Assert
Assert.AreEqual(expected, x.Current);
}
}

So, I've written my test, before my implementation, and now I know
that I will need an interface called IMyInterface, which will expose
two members, IncrementCounter which is a method, and Current which is
a property. I also know that I will need an implementation of that
interface called MyInterfaceImplementation.

When I've written my interface and it's implementation, I run my test
again, it passes. I then run my nCover to get a coverage report, and I
notice that it returns 100%. Next, I refactor the code I have just
written, which as a consequence could mean that I end up with PRIVATE
members on my MyInterfaceImplementation class, however when we run our
nCover report again we will notice that we still have 100% code
coverage, which includes my private members!

This is a result of following the principle whereby I ONLY WRITE THE
CODE I NEED IN ORDER TO PASS THE TEST.

Continuing on, once we have only written the code we needed in order
to pass our test, and we have written all the functionality we can
currently think of as a requirement, we will find that our new class
is 100% testable, it contains, private, public, and protected members
and also has 100% code coverage.