Is Typemock Isolator Evil - Round N+1

Every few months the argument for and against the advance abilities of the Isolator mocking framework burst again. This time it started with this post: Test driven design – Willed vs. Forced Designs

Disclaimer: I used to work for Typemock company and was in charge for a long time over the development of the framework. so I claim no kind of objectivity .

the argument for and against usually circle around the following:

on one side, people claim that Isolator "breaks" the language barriers and, by allowing any kind of design to be implemented will end up in helping to build a poorly designed system.

on the other side, by allowing the freedom to design at will Isolator shift the responsibility back to the developer allowing him to choose the "best" design as he sees fit.

here are some points I want to comment on:

If you need Isolator you have a bad design

Actually that one is in most cases true. However the following claim "you have bad design" also holds for too many cases as well. Yes I'm saying that most systems out there are poorly designed. I'm also saying that most software project out there will fail. What I don't like about the initial claim is the conclusion that usually follows:

If you need isolator when you have poor design, usage of isolator will end up with a poor design.

That statement is plain wrong, you will end up with poor design unless you learn how to design better. The effect Isolator (or any tool for that matter) will have on a team design skills is minimal at best. Pragmatically speaking if you are are working on a legacy system isolator is probably the better choice no matter what. If you are working on a newly project and you just start out TDD, most likely using isolator will increase the chances you'll be able to stick with it. (adding the need to relearn design at this stage is soo much harder), and if you're working on a new project and you do know how to TDD. Then you should just know better and be able to safely use the tool. If you don't then you really do have a problem.

Isolator breaks the natural barriers of the language

Yes it does, but the statement "Statics are the death of testability" which actually means "don't use static methods" adds barriers to the language which is not there. so what's the better approach? again I don't know. It really depends on your personal preferences and has nothing to do with what is the best design

Actually there's no such thing is the best design. Every design must evolve always to fit the system needs.

Show me a concrete example

example number 1:

many systems have a dependency on the time of day. the naive way to approach that is to use DateTime.Now. but oops that one cant be faked (its a static method) making it a real pain to test. so experienced programmer introduce the ITime interface wrapping the system time with an interface and then adding some concrete code to make it work, all for the sake of testability. here's an example taken from the testify project on how to implement this:

public static class SystemClock {

   private static DateTime? fixedTime;

   public static DateTime Now {
       get {
           if (fixedTime.HasValue)
               return fixedTime.Value;
           return DateTime.Now;
       }
   }

   internal static void Set(DateTime value) {
       fixedTime = value;
   }

   internal static void Reset() {
       fixedTime = null;
   }
}

Please enlighten me as why this is better/simpler as opposed to use of DateTime.Now.

example number 2:

I have a class A depends on Class B. Class B is the ONLY concrete class implementing the interface ISomeInterafce (and most likely this will hold true forever). Class A is the only place (for now and most likely forever) ISomeInterface is used. yes this is a simple example but since I'm inventing it, I get to set the rules.

and there are several ways to approach this:

1. Use some IOC container to instantiate B and send it to A. a valid OO way with many benefits however in my concrete example (and yes I'm the one setting the rules). I don't have a true need for a full pledged IOC yet, and this very simple scenario wont be the one causing me to start using an such a big hammer

2. Use a factory - a simpler version of the IOC container idea, much more light weight. but still at this point of time (and yes I get to make the rules) under the specified circumstance it falls under the YAGNI directive. If the situation changes (i.e. more places will use ISomeInterafce or more "kinds" of ISomeInterafce will evolve) a factory will be used but for now I don't really need that.

3. Instantiate B somewhere and pass it into A (the simplest form of DI) - a very simple solution which is valid under this scenario. the down side for it are , that it exposes some inner working details of A which may not be a good idea AND most likely it only shifts the problem to someplace else.

4. Just use a new statement somewhere inside A (lets say constructor) - I like this way. Its the simplest thing that can possibly work, and I'm not tied to the "design for testability" chains, so I can do that. and just before I get chopped, yes taken outside this context of this simple concrete example is most likely not a good strategy.

I want to make the Choices. I'm the professional trained to do them. I wont stand being TOLD how to do my job, not by a person, and especially not by a tool.

Read more »

Posted in: Design,Engineering Practices,Scrum. Random Thoughts,tools,Typemock

ScrumBut - No Release Planning

"Were doing Scrum-But ..."

The ScrumBut phenomena has started to appear more and more as scrum has started to take its hold in the industry. I want to add one ScrumBut i was in charge of and it went like this:

We were doing scrum but: We had no release planning.

At the time we were undergoing so many directional shifts that each time we tried to flesh out a release plan, it changed drastically causing any planning effort to fail. Also our acting PO wasn't involved enough, a fact which also contributed to to difficulty of achieving a stable enough release plan. So we went and continued without it.

And actually it wasn't a complete disaster, we achieved a very short sprint length of 1 week, we added to that various engineering practices like TDD, CI and Pair programming and we managed to maintain a constant development rhythm with good quality.

however we were missing several big things, in fact we completely gave up on any attempt to see and track the bigger goals. I wasn't able to predict anything beyond the end of the current sprint and the developers found it difficult to understand the "bigger" picture. Eli has described the problem:

So if the management has a goal: Close Sale with Customer [put huge customer], and to do this the R&D must implement the ABC feature. We might reach the end of the month without that feature being implemented and management won’t know about it.

 

The thing is, that what we were doing seriously lacking, and due to us changing the process and failing to do it properly we got the what can only be described as the logical result.

When you don't plan on the higher level (release), you cant project beyond the micro level (sprint). You don't measure overall progress, and you lose the ability to manage on that high level. Naturally you cant be sure when things will be done or when things are not going according to plan.

At Typemock the solution for this was to adapt an "integrity" based management approach, and so far it seems to be working for them. However what Eli reports as "The differences between Scrum and integrity" is actually based on a something which is Scrum based but is too lacking to represent actual Scrum done properly.

Read more »

Posted in: Agile practices. Planning,Scrum,Typemock

How to Mock a Static Method

More and more i encounter places and people that still insists that static methods cant be mocked and therefore makes unit testing code which uses them harder.

Here's a very short example on how a static method CAN be mocked using the proper toolset in .Net, Java and C++. The ability to mock static methods is part of the mocking libraries I am using (Isolator for .Net, PowerMock for Jave and MockItNow for C++).

Design wise, I do NOT claim that using static methods is a good practice. In fact I am NOT a design expert, and therefore I don't have any sort of claim on what are good design practice and what are bad design practice. What I do claim is that unit tests can be written to code even if it does use static methods.

In all the examples I'll be using a class which looks something like this:

public class ClassWithStaticMethod
{
   public static int StaticMethodReturnFive()
   {
       return 5;
   }
}

.NET

[TestMethod()]
[Isolated]
public void MockStaticMethodToReturnSix()
{
   Isolate.WhenCalled(() => ClassWithStaticMethod.StaticMethodReturnFive()).WillReturn(6);

   int actual = ClassWithStaticMethod.StaticMethodReturnFive();
   Assert.AreEqual(6, actual);
}

Java

@Test
@PrepareForTest(ClassWithStaticMethod.class)
public void MockStaticMethodToReturnSix()
{
    mockStatic(ClassWithStaticMethod.class);
    expect(ClassWithStaticMethod.StaticMethodReturnFive()).andReturn(6);
    replay(ClassWithStaticMethod.class);

    int actual = ClassWithStaticMethod.StaticMethodReturnFive();
    Assert.assertEquals(6, actual);
}

C++

TEST(MockStaticMethodToReturnSix)
{
   Mocker mocker;

   ClassWithStaticMethod* fake = new ClassWithStaticMethod();
   REGISTER(ClassWithStaticMethod::StaticMethodReturnFive);
   RECORD
   {
       EXPECT_RETURN_ALWAYS(ClassWithStaticMethod::StaticMethodReturnFive(),6);
   }

   int actual = ClassWithStaticMethod::StaticMethodReturnFive();
   CHECK(6==actual);
}

Read more »

Posted in: C++,Java,Mocking,tips,Typemock,Unit Tests

VB .NET Mocking

Typemock has released a new version yesterday (5.2) in which they included a new API for VB developers. unlike previous version this time the VB API was specially planned and designed in VB, for VB developers. Hopefully using special constructs of the VB language will result in an easier and more intuitive API. With my limited experience using the VB language i cant say I can be a good judge for that.

For blogger's out there, Typemock is also offering a chance to win a free license you can check it out here.

beside the VB API the new version also continue on improving the C# AAA syntax adding to it capabilities such as true indexers, better repeating mechanisms and some more.

One important thing to watch out from, is that default mock creation has changed (taken from Typemock Blog):

Another change in this version is the default behavior for creating fake objects. It has been changed to Members.ReturnRecursiveFakes when creating a  fake instance without any parameters.

Read more »

Posted in: AUT,Mocking,tools,Typemock,Unit Tests