How Hierarchy works with TypeMock

Eli Lopian    .NET Tests    

Mocking methods in the hierarchy of the code is supporting in TypeMock.NET.
There is nothing like examples so here is our hierarchy.

We are mocking type Second

1. A mocked method, will not be mock when called from a derived class.
   Example: Mocking DoSomething() will not be mocked if it is called from Third.
   

   Mock mock = MockManager.Mock(typeof (Second));
   mock.ExpectCall("DoSomething");
   
   Third third = new Third();
   // this won't be mocked
   third.DoSomething();
   

2. A mocked method defined in a base type will be mocked only when called from the mocked type.
   Example: Mocking InFirst() will only be mocked when called from Second.

   Mock mock = MockManager.Mock(typeof (Second));
   mock.ExpectCall("InFirst");
   
   Second second = new Second();
   // Will be mocked even if it is defined in First
   second.InFirst();
   
   

3. An overloaded method will be mocked in the base class too when called from the mocked type.
   Example: Mocking Overridden() will be mocked also when Second calls base.Overridden()
   

   // if we call the base
   public void DoSomething()
   {
      base.Overridden();
   }
   
   Mock mock = MockManager.Mock(typeof (Second));
   mock.ExpectCall("Overridden");
   
   Second second = new Second();
   // base.Overridden will be mocked
   second.DoSomething();
   
   

4. To specifically mock only a base method use the new: mock.CallBase
   Example: Mocking Overriden() will be mocked ONLY when Second calls base.Overridden()
   

   // if this is the method
   public override void Overridden()
   {
      base.Overridden();
   }
   
   Mock mock = MockManager.Mock(typeof (Second));
   mock.CallBase.ExpectCall("Overridden");
   
   Second second = new Second();
   // here the Second.Overridden will be called and First.Overridden Mocked
   second.Overridden();
   
   

How Dynamic Mock Objects can Auto Pilot

Eli Lopian    .NET Tests    

When creating a Mock Object from an interface, the object is set in Strict mode. This means that any unexpected call to the object will fail.
The reason is quite simple. It is because there is no real implementation of any methods.

Since version 3.6.1 Dynamic Mock Objects will have a real default implementation. The implementation will return default values when ever a method is called and will build properties to act as simple properties (after setting a property, you will be able to read it).

To enable this feature you will have to turn off the strictness of these mocks.

Here is an example interface

public interface IImplement
{
   int MyProperty
   {
      get;
      set;
    }
}

Here is test that shows the auto pilot property works.

Natural Mocks:

[Test]
public void AutoPilotProperties()
{
   IImplement mockImpl = (IImplement)RecorderManager.CreateMockedObject(
     typeof(IImplement), StrictFlags.ArbitraryMethodsAllowed);

   mockImpl.MyProperty = 10;
   Assert.AreEqual(10, mockImpl.MyProperty);
}

Reflective mocks:

[Test]
public void AutoPilotProperties()
{
   MockObject mock = MockManager.MockObject(typeof(IImplement));
   IImplement mockImpl = mock.Object as IImplement;
   mock.Strict = false;

   mockImpl.MyProperty = 10;
   Assert.AreEqual(10, mockImpl.MyProperty);
}

Multiple Asserts in a Single Unit Test

Eli Lopian    .NET Tests, TDD    

There is a debate going on about having one assertion per test.

James Avery argues that what he’d really like to see in a unit test framework is the ability to run (and fail) multiple asserts within the same test and Roy Osherov still argues that there is value in having one assertion only.

I am less inclined to force a one assertion per test as it might add unneeded burden on the developer, who has to set up the same test scenario for each test. This will require Refactoring the test and Extracting a setup method. On the other hand I would not want the tests to continue to run once the first test has failed, as Roy correctly pointed out, we are in a dirty state.

As we know, there is no Silver Bullet we are going to have to rely on the developers to take the call and decide what is best for them.

I am in favor developers being guided by:
The Test Should Test Only ONE scenario

This does not mean one assert! it means one scenario.

If we need to assert several items to verify that the scenario works, we should do it in the same test (This is how all mocking frameworks work anyway).

In the examples that James brings, each test verifies one scenario but requires several asserts. I believe that this is good practice.

TestDriven.NET 2.0 is released

Eli Lopian    .NET Tests    

Jamie has just released TestDriven.NET 2.0. 
I have worked with Jamie quite a bit on the TypeMock.NET integration and now using TypeMock with Zero Friction Testing is easier then ever.

The integration enables testing with TypeMock with a click of  button, it also enables automatic linking of TypeMock with NCover.

Way to go Jamie.

How to Mock Singletons in 3 Simple Ways

Eli Lopian    .NET Tests    

Want to mock Singletons?

Here are 3 simple ways to mock a Singletons.

1. Use MockAll

When the static constructor is not mocked just use MockAll

Mock theSingletonMock = MockManager.MockAll(typeof(Singleton),
  Constructor.StaticNotMocked);

or to mock the constructor

Mock theSingletonMock = MockManager.MockAll(typeof(Singleton),
  Constructor.NotMocked);

Remember that you can only MockAll once until all mocks are verified/cleared. To retrieve the mock simply use:

Mock theSingletonMock = MockManager.GetMockAll(typeof(Singleton));

2. Use a MockObject

When the static constructor needs to be mocked we can return a mocked object whenever Instance is called 

// make sure that all constructors are mocked
MockManager.MockAll(typeof(Singleton), Constructor.Mocked);
// create mocked singleton object  
MockObject theSingletonMock = MockManager.MockObject(typeof(Singleton),
  Constructor.Mocked);
// return our mocked singleton 
theSingletonMock.ExpectGetAlways("Instance", theSingletonMock.Object);

Note: This will only work when the static constructor is mocked.
Also watch out for beforeFieldInit issues.

3. Set the instance Field

Another way to mock static constructors of singletons is to set the instance field.

MockObject theSingletonMock = MockManager.MockObject(typeof(Singleton),
  Constructor.Mocked);
ObjectState.SetField(typeof(Singleton), "instance",
  theSingletonMock.Object);

remember that you are changing a field so it is best to reset the field after the test. Here is one way.

MockObject theSingletonMock = MockManager.MockObject(typeof(Singleton),
  Constructor.Mocked);
object keptSingleton =
   ObjectState.GetField(typeof(Singleton), "instance");
try
{
    ObjectState.SetField(typeof(Singleton), "instance",
       theSingletonMock.Object);

    // the test...
}
finally
{
    ObjectState.SetField(typeof(Singleton), "instance",
      keptSingleton);
}

Note: As before this will only work when the static constructor is mocked.

Don’t call us we’ll call you

Eli Lopian    .NET Tests    

Testing how events are hooked up to your system can be tricky, TypeMock.NET makes this easier.

Testing the plumbing

Lets see how we test a class that fires events.

Here is a snippet from a List that fires event whenever an Item is added

public class ListWithChangedEvent : ArrayList
{
    // An event that clients can use to be notified whenever the
    // elements of the list change.
    public event ChangedEventHandler ChangedEvent;

    // Override some of the methods that can change the list;
    // invoke event after each
    public override int Add(object value)
    {
        int i = base.Add(value);
        if (ChangedEvent != null)
        {
            ChangedEvent(this, EventArgs.Empty);
        }
        return i;
    }
}

(10 point to the first to find the Race Condition bug)

To test this class we can test the following scenarios:

1. No event listeners registered
2. One event listener register – gets called
3. Two event listeners registered – gets called

Testing that an event listener gets invoked is a classic interaction based test and mocking frameworks work very well with this.

Here is the second test:

[Test]
public void TestEventWorks()
{
    // Create a new list.
    ListWithChangedEvent list = new ListWithChangedEvent();

    // Try with one listener
    // add a listener
    list.Changed += new ChangedEventHandler(list_Changed);
    using (RecordExpectations record = RecorderManager.StartRecording())
    {
        // expect to be called when adding to list
        list_Changed(list, EventArgs.Empty);
    }
    // Add item to the list.
    list.Add("item 1");
    // make sure it was called
    MockManager.Verify();
}

// dummy method that is used as a placeholder
void list_Changed(object sender, EventArgs e)
{
    throw new Exception("The method or operation is not implemented.");
}
  

There is no need to create an object that uses the ListWithChangedEvent to test the list, and with this test we can verify that the event mechanism is working.

Meanwhile at the other side…

At the other end, we have a class that registers to the event and performs some action when the event is called.

Suppose we have a class that registers to the Button.Click event

public void Example()
{
   Button button = new Button();
   button.Click += new EventHandler(button_Click);
}

private void button_Click(object sender, EventArgs e)
{
   // Do Somethings here
}   

To test that the Example class works correctly when the button is clicked, the Button can be Mocked. It is then possible to make Example believe that the button was clicked (Note this feature requires version 3.6)

[Test]
public void TestThatExampleWorksWhenButtonClicked()
{
    using (RecordExpectations record = RecorderManager.StartRecording())
    {
        // mock next button and the event registration
        Button mockedButton = new Button();
        mockedButton.Click += null;
    }
    // invoke our test method that registers to button.Click
    Example();
    // Fire the event
    RecorderManager.LastMockedEvent.Fire(this, EventArgs.Empty);
    // here we test that Example works correctly
    //...

    MockManager.Verify();
  }   

When the LastMockedEvent is Fired the button_Click is invoked, and we can verify that our class handles the event correctly. The heart of this exercise is the ability to mock an event registration and then fire that mocked event

How to Debug with TypeMock.NET without losing your head

Eli Lopian    .NET Tests, Debugging    

TypeMock.NET has many internal features that allow debugging code that has some mocked methods, and although this works most of the time, there are some things you need to watch out for. All these have to do with the Visual Studio’s Property Evaluation or funceval (see Mike Stall’s – Func-eval is evil post)

Basically whenever you see in a Property value in a watch or local variable window, the debugger hijacks a thread and evaluates the property.

Now, this works fine if your properties don’t change the state of your code, once they do, this will mess up your code.

The following code:

private int count;
public int Count
{
  get { return count++; }
}

can really confuse, as while stepping with the debugger count will be increased. The same is true for TypeMock.NET expectations, as long as we are not using RepeatAlways() we are changing the state of our code.

So if we have the following expectation.

using (RecordExpectations recorder = RecorderManager.StartRecording())
{
    recorder.ExpectAndReturn(SomeProperty, 10);
}

and we break just before we call SomeProperty, and evaluate it, we will see that SomeProperty returns 10, but when we continue it won’t return that value any more and the test will fail. Very annoying.

What is worse is trying to step through the recording session. If you break while inside a recording (in the using block), TypeMock will catch all the evaluations and mock them. Using the Tracer while doing this stunt will show how the expectations are being filled…

See how NUnit.Core is being mocked
and the get_MyProperty is also mocked because of funceval calls.

Workaround

Until the debugger comes with a better API here are things to remember.

1. Don’t break while recording – There is really no reason to break there as no calls are actually made.
2. If possible mock Properties with RepeatAlways() to make sure that debugging won’t confuse.
3. This is not always possible as you might sometimes want to validate that a property was called only once, in this case just keep in mind that the debugger can change your programs’ flow
4. Turn off evaluating Properties:

• Visual Studio 2003,  go to Tools -> Options -> Debugging -> General and uncheck Allow property evaluation in variables windows
• Visual Studio 2005, go to Tools -> Options -> Debugging -> General and uncheck Enable property evaluation and other implicit function calls

Low Coupling is NOT a Silver Bullet

Eli Lopian    .NET Tests    

I will start with some more post about TypeMock and Testability issue.

• Mocking with TypeMock - Travis Illig

Holy crap, this thing is hot. In technical terms, you might call it the bomb-diggity.
I haven’t been this stoked about a technology for quite some time.

• TypeMock is wonderful - Ken Robertson

TypeMock is absolutely awesome.  No, no, it is sexy.  It is dead sexy.  TypeMock has opened up a whole new world for me in unit tests. 
Simply beautiful. 

• Some general thoughts & mocking frameworks - Miki Watts

Sorry, Travis, no offense, but when you wrote this you showed that you still don’t get the idea of unit testing and the benefits that come from them…

Question to Miki:

Is the ‘pass the interface into the method’ really a better design? Think about it for a moment. You now require the WorkingClass to know about an interface that he doesn’t really need to know about. So you are actually lowering the cohesion (by having a less encapsulated system) in order to have a lower coupled system. This is what design is all about – balance, there is no silver bullet.

So is the design balanced? or do we blindly always strive to have lower coupled system at the price of other object oriented practices?

ps. I know that you can have a design the has both options and have the WorkingClass use only methods that do not require the interface, but then you are really dirtying the code just for the tests.

Price changes

Eli Lopian    Product    

Our prices are going to rise at the beginning of Next Month. All developers who are evaluating TypeMock are highly recommend to purchase before November to enjoy our low prices.

Price Changes: (not final)

• Enterprise Edition Plus 1 Year Maintenance: $299
• Professional Edition Plus 1 Year: $199
• Annual Maintenance: $49

MailFrame’s CodeSpell

Eli Lopian    Reviews    

I had quite an embarrassing moment when Scott Hanselman who is reviewing TypeMock.NET sent me his first impressions.
The e-mails where screen-shots of spelling typo’s in TypeMock’s API’s documentation. It turns out that there are quite a few spelling mistakes in the API’s documentation.

Well, we added a task to fix all these, but as we are software developers we looked for a tool that would do the job for us.

Not Much has changed since 2005, and ZMan’s blog has a good summary of the existing tools. We tried the $50 Keyoti StudioSpell and the $29 MailFrame’s CodeSpell. I am not going to do a complete review but CodeSpell found mistakes in comments and in method/variable naming in an integrated way (without popping up other dialogs) and apart from crashing the Visual Studio when parsing non Latin text, it runs in the background and marks mistakes in the editor as you type, this will keep our spelling correct as we develop (very agile). The StudioSpell did not find all the mistake and didn’t work in a very integrated way (you must initiate the speller rather then have the speller mark mistakes with a wave).

To check end user messages StudioSpell is probably better, but for comments and method names, CodeSpell is way better, and for $29 it is a no brainer. Thanks Will Ballard