Viral Marketing

I was reminded the other day about viral marketing. There is a great FREE book on the subject at http://www.sethgodin.com/ideavirus/01-getit.html

The basic concept that ideas act like viruses. Some ideas (the successful ones) catch on and spread. The book is about how to design and present ideas so they can be easily spread and hence improve the chances of them taking off.

A good recent example of this is beer commercials. Manufacturers have started creating adverts for release on the internet. If you wrap your message in something funny people will email it to each other. Jokes on the internet move very fast indeed. The adverts spread in this manner reach millions in no time, and costs the company practically nothing.

Musical Office

I frequently work with teams that like to listen to music while developing. I hate headphones. I find they are worse than putting each developer in their own office for team communication. Better to have some music you all agree upon listening to and have an Office Jukebox.

Currently we are using WinAmp with WinAmp Web Interface. This allows anyone on the team to change track, change volume, etc.

Mocking actors and critics

Talking with Craig the other day he mentioned the names 'Actor' and 'Critic' when talking about the roles of a mock object.

Looking at the EasyMock API more this week, it seems there may be a way to use the SetDefaultValue() methods to achieve what I want. We shall see.

EasyMockNET vs NMock

Recently I have been convinced to try easy mock instead of NMock (my mocking framework of preference). Here is how I went...

I started using NMock when all that was available was a dll you could download from sourceforge. There was absolutely no documentation and no source code. I ended up using Reflector (great tool) to work out how to use it. NMock soon became an indispensable tool.

There are a choice of mocking frameworks now (a good list is available on testdriven.net). Most are basically the same. I have been happy with NMock but it does have one problem though. Here is an example of an NMock Test.

[Test]
public void LoadingScriptWithSingleKnownAction()
{
 DynamicMock mockActionLoader = new DynamicMock(typeof(IDbActionLoader));
 IDbActionLoader actionLoader = (IDbActionLoader)mockActionLoader.MockInstance;

 DynamicMock mockAction = new DynamicMock(typeof(IDbAction));
 IDbAction action = (IDbAction)mockAction.MockInstance;

 DBScriptLoader loader = new DBScriptLoader();
 loader.RegisterActionLoader(actionLoader);

 string scriptTxt = @"CreateTable
 Name: newTable";

 mockActionLoader.ExpectAndReturn("HasName",true,"CreateTable");
 mockActionLoader.ExpectAndReturn("LoadAction",action,scriptTxt);
   
 IDbScript script = loader.LoadScript(scriptTxt);
 Assert.AreEqual(1,script.Length);
 Assert.AreEqual(action,script[0]);
 mockActionLoader.Verify();
}

Notice the "ExpectAndReturn" calls require you to specify the name of the method you are expecting as a string. The problem with this is that refactoring tools (i.e. Resharper) doesn't know these are method names. If you rename one of these methods you will have to manually rename the string to match. This sort of test maintenance increases the cost of having tests. Anything that increases the cost of tests is bad as it pushes you towards writing less tests and that is where the map is marked 'here be monsters'.

EasyMock has another way of writing tests. The mock object that is created has two modes. It starts in recording mode. To set expectations you just call methods on the object. When you have set all your expectations you then switch all the objects to replay mode. To set the return value of a method call you have to call 'SetReturnValue' just after the method has been called. This is ugly, but luckily there is some syntactic sugar to wrap this up in most cases. Here is the same test again in EasyMock (using the ExpectAndReturn syntax).

[Test]
public void LoadingScriptWithSingleKnownAction()
{
 MockControl mockActionLoader = MockControl.CreateStrictControl(typeof(IDbActionLoader));
 IDbActionLoader actionLoader = (IDbActionLoader)mockActionLoader.GetMock();

 MockControl mockAction = MockControl.CreateStrictControl(typeof(IDbAction));
 IDbAction action = (IDbAction)mockAction.GetMock();

 DBScriptLoader loader = new DBScriptLoader();
 loader.RegisterActionLoader(actionLoader);

 string scriptTxt = @"CreateTable
 Name: newTable";

 mockActionLoader.ExpectAndReturn(actionLoader.HasName("CreateTable"),true);
 mockActionLoader.ExpectAndReturn(actionLoader.LoadAction(scriptTxt),action);

 mockActionLoader.Replay();
 mockAction.Replay();

 IDbScript script = loader.LoadScript(scriptTxt);
 Assert.AreEqual(1,script.Length);
 Assert.AreEqual(action,script[0]);

 mockActionLoader.Verify();
 mockAction.Verify();
}

ExpectAndReturn in Easymock is the syntactic sugar to make the interface look like NMocks. The following are equivalent...

mockActionLoader.ExpectAndReturn(actionLoader.HasName("CreateTable"),true);

or

actionLoader.HasName("CreateTable");
mockActionLoader.SetReturnValue(true);

In the ExpectAndReturn methods the first parameter is ignored. It is just a nice place to put your method call to the mock object.

I started using EasyMockNET on a new project and quickly found that a simple helper class makes using EasyMock even easier.

public class MockManager
{
 private ArrayList mocks = new ArrayList();
 public MockControl CreateMock(Type typeToMock)
 {
  MockControl strictControl = MockControl.CreateStrictControl(typeToMock);
  mocks.Add(strictControl);
  return strictControl;
 }

 public void StopRecordingAndStartPlayback()
 {
  foreach (MockControl mock in mocks)
  {
   mock.Replay();
  }
 }

 public void VerifyAllExpectations()
 {
  foreach (MockControl mock in mocks)
  {
   mock.Verify();
  }
 }

 public void ResetAllExpectations()
 {
  foreach (MockControl mock in mocks)
  {
   mock.Reset();
  }
 }
}

By creating an instance of this class in the SetUp method of the test fixture, and using CreateMock instead of MockControl.CreateStrictControl it allows you to verify, reset or replay all the mocks in one go.

One problem I have with mock objects (in general) is how easy it is to make your test dependent on the implementation details of the class under test. A good unit test should verify the external behavior of the class, not the method it uses. The very nature of mock objects forces you to set expectations on how a class is used. I don't care if the calling class uses my "Has Items" method as long as it doesn't try to access the items when there aren't any. If the calling class decided to call this method two or three times I don't really care either. So... I want to be able to say "method, don't expect to be called, but if you are with these parameters then return this value". I have added such a method to my local version of NMock. I guess I will have to add something similar to EasyMockNET.

When I am writing a test with mock objects I find that I use them in three ways. One is to set up data so I can put the class under test into a known state before I begin my real test. Another is as a simple data object that I verify is passed around correctly (no expectations are set). The other is the actual expectations I wish to validate for the test. Again the first set of expectations I don't actually want to verify for this test (they should be tested elsewhere). Thoughtfully EasyMock provides a Reset method which throws away all the expectations set so far. You can therefore set up mocks to return values, call the init methods on your class under test so its state is set, then call Reset on all mocks. You are not ready to set your real expectations.

So... My conclusion? I'm using EasyMockNET on all my projects from now on. The fact that refactorings tools can keep my tests up to date is a big win for me. If I change my mind later, I'll let you know ;)

How to change your life

I have been reading a great book recently "It's your life. What are you going to do with it?" by Anthony Grant PhD and Jane Greene.

It is a book about how to be your own life coach. Every piece of advice is practical and based on research. I recommend giving it a read if you have any unfulfilled goals.

One gem I have taken away from it so far (and it is typical of this book that the advice seems obvious once you hear it) is...

If you want to make a change in your life, there are several phases that you go through.
* Preconception - before you start thinking of making a change.
* Contemplation
* preparation
* Action - start to take steps
* Maintenance - conscious effort required to follow new behavior (leading to relapse or termination)
* Relapse - fall back to old habits (leading back to Contemplation)
* Termination - The new behavior is now part of your personality

So.. You can help make changes be facing each of these phases full on.
When it occurs to you that you should change something evaluate the pro's and con's on paper. This will help you decide if you really want to make the change. This will lead you quickly to the preparation stage. Plan what changes you want to make to achieve your goal. Make them attainable and measurable. This readies you for Action. Put in place your plans. Measure your progress in a way that you can visibly see how you are getting on. By measuring how you are progressing you can use feedback to adjust your goals to ensure they are attainable. This will help you enter the Termination stage. Even if you don't attain your original goal, from this new position your original goal may now be attainable. Relapse is expected and is not failure. Don't beat yourself up for it. Return to Contemplation and reevaluate your original reasons for wanting to make the change. This is where having defined a good list of pro's and con's at the beginning will help. Review them. If they are still correct then this should help get you quickly back to preparation. Take the time to reevaluate the plans you previously made. Adjust them if they are not measurable and attainable.

and repeat.