6428

Typemock Developers Community Site Updated

Typemock has updated its Developers Community Site with new sections.

Besides the forums, there's a new add-ons page where anyone can share her/his tools or snippets (I guess I'll have to brush up my Typemock Snippets For Visual Studio to add there) and an experts page (guess who's there).

Typemock fan Meet the experts

Upcoming Typemock Webcast on March 12

Typemock is having a special Webcast on Wednesday March 12, 16:00 GMT

The live demo will include:

  • The Support of the new .NET 3.5 framework and specifically how to mock LINQ statements.
  • The improved IDE based on using colors to emphasize mocked methods.
  • Seamless integration with  Microsoft’s Visual Studio 2008.

It is also an opportunity to meet Typemock’s development team, ask questions online and share some tips.

.....and one of you can win a Nintendo Wii during in the webcast!

Click here to participate in the Webcast

TypeMock Isolator 4.2 Released

TypeMock has released version 4.2 of its mocking framework: TypeMock Insulator. Check out the release notes.

My four favorite new features in this release are:

Improved mock chaining

(If you want to learn more about chains, read this post from Gil)

Take this class to be tested:

public class TestedClass1
{
    public IDictionary<string, object> Dictionary
    {
        get { throw new NotImplementedException(); }
    }

    public object Method(bool cond)
    {
        if (cond)
        {
            return Dictionary["true"];
        }
        else
        {
            return Dictionary["false"];
        }
    }
}

The following test:

[TestMethod]
[VerifyMocks]
public void TestMethod1()
{
    object trueObject = new object();
    object falseObject = new object();

    TestedClass1 target = RecorderManager.CreateMockedObject<TestedClass1>();

    using (RecordExpectations recorder = RecorderManager.StartRecording())
    {
        recorder.DefaultBehavior.CheckArguments();

        recorder.ExpectAndReturn(target.Dictionary["true"], trueObject);
        recorder.FailWhenCalled(target.Dictionary["false"]);
    }

    object value = target.Method(true);
    Assert.AreEqual(trueObject, value);
}

Would simply fail with:

Test method TestProject1.UnitTest1.TestMethod1 threw exception:  TypeMock.VerifyException: 
TypeMock Verification: Method TestProject1.TestedClass1.get_Dictionary() has 1 more expected calls
.

Now, it just passes.

Debugger evaluation doesn't change the test behavior

Now you can debug your code without having to change your tests. You can query mocked values without influencing your tests.

You can do this and still have the test passing:

Debugger Support

The debugger can be run inside a recording block without confusing the test

You can now step into the recording block and debug it without affecting the recording process and the test.

Recording Block

When you step in the debugger into a mocked method, the mocked method will be painted

When you step into a mocked method (or property) I'll see that it's mocked.

Visual Studio Cues

Typemock Insulator Is Typemock Isolator

Yesterday I made a mistake with the name of the next version of TypeMock. The real name is TypeMock Isolator. Whatever the name is, you should try it out.

TypeMock Insulator 4.2 Beta Publicly Available

TypeMock (now called) Insulator 4.2 Beta is publicly available. Check out the release notes.

One of my favorite new features is the improved mock chaining.

Take this class to be tested:

public class TestedClass1
{
    public IDictionary<string, object> Dictionary
    {
        get { throw new NotImplementedException(); }
    }

    public object Method(bool cond)
    {
        if (cond)
        {
            return Dictionary["true"];
        }
        else
        {
            return Dictionary["false"];
        }
    }
}

The following test:

[TestMethod]
[VerifyMocks]
public void TestMethod1()
{
    object trueObject = new object();
    object falseObject = new object();

    TestedClass1 target = RecorderManager.CreateMockedObject<TestedClass1>();

    using (RecordExpectations recorder = RecorderManager.StartRecording())
    {
        recorder.DefaultBehavior.CheckArguments();

        recorder.ExpectAndReturn(target.Dictionary["true"], trueObject);
        recorder.FailWhenCalled(target.Dictionary["false"]);
    }

    object value = target.Method(true);
    Assert.AreEqual(trueObject, value);
}

Would simply fail with:

Test method TestProject1.UnitTest1.TestMethod1 threw exception:  TypeMock.VerifyException: 
TypeMock Verification: Method TestProject1.TestedClass1.get_Dictionary() has 1 more expected calls
.

Now, it just passes.

Visual Studio cues are nice too.

POUT – That’s The Way I Like It

POUT - Plain Old Unit Testing

Read all about it here.

TDD Proven Effective! Or is it? – by Jacob Proffitt

Jacob Proffitt has some comments about the the paper on the effectiveness of test-first approach to programming.

Here are a few excerpts:

If you're like me, you understand the problem better after implementing it and can thus create more relevant tests after the fact than before. I know better where the important edge-cases are and how to expose them and that could mean that my tests are more robust.

Anyway, without question, testing first leads to having more tests per functional unit. The question is if this is valuable.

TypeMock: How to Make Reflective Mocks More Natural

Like I said before, this as been on the back of my mind for a while.


A while back I introduced a way to get the MethodInfo of a method in a strongly typed way using LINQ, and that's how I'm going to make Reflective Mocks more Natural.


Well, it's as easy as this:

public static class MockExtender
{
public static IParameters ExpectAndReturn<T1, T2, TResult>(this IMockControl mock, Expression<Func<T1, T2, TResult>> expression, object ret, params Type[] genericTypes)
{
return mock.ExpectAndReturn((expression.Body as MethodCallExpression).Method.Name, ret, genericTypes);
}
}

(For now, I'll leave to someone else the implementation of the rest of the overloads)


With this implementation it's possible to handle static classes (a limitation of Fredrik's implementation).


As for private methods, just let Visual Studio (2008, in this sample) and TypeMock do their magic.


So, to test this class:

public static class Class1
{
public static string PublicMethod(string param1, int param2)
{
return PrivateMethod(param2, param1);
}

private static string PrivateMethod(int param2, string param1)
{
throw new NotImplementedException();
}
}


We just write this test:

[TestMethod()]
public void PublicMethodTest()
{
string param1 = "param";
int param2 = 5;
string expected = "return";
string actual;

Mock targetMock = MockManager.Mock(typeof(Class1));

targetMock.ExpectAndReturn((int i, string s) => ClassLibrary1.Class1_Accessor.PrivateMethod(i, s), expected).Args(param2, param1);

actual = Class1.PublicMethod(param1, param2);

Assert.AreEqual(expected, actual);
}


How about this for clean and simple?

TypeMock: Making Reflective Mocks More Natural

I've been thinking about this for a while. Seems like someone beat me to it.

Is Testing The Ultimate Goal?

Whenever you throw TDD without worshiping it you turn yourself immediately in a victim of religious fundamentalists. TDD is a gift from god, it's good, it's cool and should never be questioned. It's a dogma.

Frans Bouma complains about it and the lack of scientific proof of the fact that TDD is really useful and good. Phil Haack throws a paper at him (which I haven't read - just looked at) but, from his own comments, doesn't dismiss Frans's point.

Why are we testing code anyway? What does it prove? According to Frans, not much. I'll have to agree with Frans on this. In summary, first you need to prove (or have proof) that what you are going to code is the right thing. Only then you can prove that you've done it correctly.

This goes even further when frameworks like TypeMock are considered too powerful. They are seen as evil in the eyes of the purists. Roy Osherove questions his readers and TypeMock community about this.

While we have to have in mind Frans' post about correctness provability, Travis does make a good point when he questions "Design for testability vs. API as a deliverable".

My bottom line in this subject is that testing tools are just tools like any other tools use in software development. The fact that they are becoming so good and powerful just changes what tools we use and how we use them.

I like compiled languages because they give me confidence over interpreted languages, because I can assert that although my code might have some errors on what it does it doesn't have any errors on how it was written.

On another level, unit testing and mock frameworks give me confidence that my code will do exactly what I intended it to do. Which might still not be correct.