markhneedham/blog huggingface dataset:
F#: String.Split with a multi character delimeter
Date: 2010-01-05 23:10:56

In my continued efforts at http://osherove.com/tdd-kata-1/[Roy Osherove's TDD Kata] I've been trying to work out how to split a string based on a delimeter which contains more than one character.

My original thinking was that it should be possible to do so like this:

[source,ocaml]
----

"1***2".Split("***".ToCharArray());;
----

I didn't realise that splitting the string like that splits on each of the stars individually which means that we end up getting 2 empty values in the result:

[source,text]
----

val it : string [] = [|"1"; ""; ""; "2"|]
----

If we want to split on '***' then we have to pass it in as a value in a string array:

[source,ocaml]
----

"1***2".Split([| "***" |], StringSplitOptions.None);;
----

That way we only get the 1 and 2 which is what we want:

[source,text]
----

val it : string [] = [|"1"; "2"|]
----

I'd expected there to be an overload which takes in a string and then just splits on that but since there isn't this isn't a bad alternative.

Sam Allen has http://dotnetperls.com/string-split[a very interesting article which covers all sorts of way to split different types of strings].
Automapper: Don't forget Mapper.Reset() at the start
Date: 2010-01-27 07:57:22

I wrote about http://www.markhneedham.com/blog/2010/01/22/automapper-first-thoughts/[my first thoughts using Automapper] last week and although I realised that it makes use of the static gateway pattern we ran into a problem where two consecutive calls to a method using AutoMapper always returned the same value for one of the mappings.

The code was roughly like this:

[source,csharp]
----

public Bar CreateNewBar(Bar originalBar, string someNewValue)
{
	Mapper.CreateMap<Baz, Baz>()
      .ForMember(x => x.Id, opts => opts.Ignore())
      .ForMember(x => x.SomeProperty, opts => opts.MapFrom(source => someNewValue));
}
----

In our test everything worked fine because we were only calling the method once but when testing it out we were making multiple calls to the method and always receiving the same value for 'someNewValue'.

I hadn't quite pieced together that each mapping was probably only created once for each source/destination pair. I thought it would be recreated each time but browsing through the code we can see that's what's going on:

http://code.google.com/p/automapperhome/source/browse/trunk/src/AutoMapper/Configuration.cs[Configuration.cs]

[source,csharp]
----

public IMappingExpression CreateMap(Type sourceType, Type destinationType)
{
   var typeMap = CreateTypeMap(sourceType, destinationType);

   return new MappingExpression(typeMap, _serviceCtor);
}
----

[source,csharp]
----

public TypeMap CreateTypeMap(Type source, Type destination)
{
   TypeMap typeMap = FindExplicitlyDefinedTypeMap(source, destination);
				
   if (typeMap == null)
   {
   ...
   }
   return typeMap;
}
----

[source,csharp]
----

private TypeMap FindExplicitlyDefinedTypeMap(Type sourceType, Type destinationType)
{
   return _typeMaps.FirstOrDefault(x => x.DestinationType == destinationType && x.SourceType == sourceType);
}
----

We put a test which called the method 'CreateNewBar' method twice to make sure that was actually the problem and then made use of the 'Reset' method on 'Mapper' to avoid the problem:

[source,csharp]
----

public Bar CreateNewBar(Bar originalBar, string someNewValue)
{
    Mapper.Reset();
	Mapper.CreateMap<Baz, Baz>()
      .ForMember(x => x.Id, opts => opts.Ignore())
      .ForMember(x => x.SomeProperty, opts => opts.MapFrom(source => someNewValue));
}
----
Nant: Populating templates
Date: 2010-01-16 00:13:30

One of the common tasks that we need to do on every project I've worked on is ensure that we can create a web.config file for the different environments that we need to deploy our application to.

Nant has quite a neat task called 'http://nant.sourceforge.net/release/0.85-rc3/help/filters/expandproperties.html[expandproperties]' which allows us to do this quite easily.

In our build file we would have the following:

build-file.build

[source,text]
----

  <property name ="configFile" value="${environment}.properties" readonly="true"/>
  <if test="${not file::exists(configFile)}">
    <fail message="Configuration file '${configFile}' could not be found." />
  </if>
  <include buildfile ="${configFile}" />

  <target name="GenerateConfigFiles">
    <foreach item="File" property="TemplateFile">
      <in>
        <items>
          <include name="ProjectDirectory/**.template"/>
        </items>
      </in>
      <do>
        <copy file="${TemplateFile}" tofile="${string::replace(TemplateFile,'.template','')}" overwrite="true">
          <filterchain>
            <expandproperties />
          </filterchain>
        </copy>
      </do>
    </foreach>
  </target>
----

There would be corresponding '.template' and '.properties' files containing the various variables we want to set, like so:

dev.properties

[source,text]
----

 <project>
	 <property name="SomeHost" value="http://my-host.com:8080"/>
 </project>
----

web.template.config

[source,text]
----

<?xml version="1.0"?>
...
<configuration>
   <appSettings>
      <add key="SomeHost="${SomeHost}"/>
   </appSettings>
</configuration>
...
----

We would call the build file like so:

[source,text]
----

nant -buildfile:build-file.build GenerateConfigFiles -D:environment=dev
----

We can then change that 'environment' variable depending which one we need to generate the configuration files for.
Coding: Missing abstractions and LINQ
Date: 2010-01-17 19:09:35

Something which I've noticed quite a lot on the projects that I've worked on since C# 3.0 was released is that lists seem to be passed around code much more and have LINQ style filters and transformations performed on them while failing to describe the underlying abstraction explcitly in the code.

As a result of this we quite frequently we end up with this code being in multiple places and since it's usually not very much code the repetition goes unnoticed more than other types of duplication might do.

A typical example of this might be the following:

[source,csharp]
----

public class SomeFooHolder
{
	public List<Foo> Foos { get; set }
}
----

An example of how this might be used is like so:

[source,csharp]
----

var someFooHolder = new FooHolder(...);
someFooHolder.Foos.Select(f => f.Completed);
----

That code would typically be repeated in other places in the code where we want to get all the completed foos.

Although it's a simple change, as a first step I prefer to make that concept more explicit by putting 'CompletedFoos' on 'SomeFooHolder':

[source,csharp]
----

public class SomeFooHolder
{
	public List<Foo> Foos { get; set; }
	public List<Foo> CompletedFoos
	{
		get { return Foos.Select(f => f.Completed); }
	}
}
----

Perhaps an even better solution would be to create an object 'Foos' to encapsulate that logic further:

[source,csharp]
----

public class Foos
{
	private readonly List<Foo> foos;

	public Foos(List<Foo> foos)
	{
		this.foos = new List<Foo>(foos.AsReadOnly());
	}

	public Foos Completed
	{
		get { return new Foos(foos.Select(f => f.Completed)); }
	}
}
----

As I've written about previously http://www.markhneedham.com/blog/2009/07/24/wrapping-collections-inheritance-vs-composition/[I prefer to wrap the list rather than extend it] as the API of 'Foos' is more expressive since we don't have all the list operations available to any potential users of the class.
C# Object Initializer: More thoughts
Date: 2010-01-10 18:52:22

I wrote previously about http://www.markhneedham.com/blog/2009/02/16/c-object-initializer-and-the-horse-shoe/[my dislike of C#'s object initializer syntax] and while I still think those arguments hold I came across an interesting argument for why it is a useful feature in http://msdn.microsoft.com/en-us/magazine/ee291514.aspx[Jeremy Miller's MSDN article on creating internal DSLs in C#].

In the article Jeremy works through an example where he builds up a 'SendMessageRequest' first by using a fluent interface and then by making use of object initializer syntax.

The fluent interface example reads like this:

[source,csharp]
----

public void SendMessageFluently(FluentMessageSender sender)
 {
     sender
         .SendText("the message body")
         .From("PARTNER001").To("PARTNER002");
 }
----

Compared with the object initializer version which looks like this:

[source,csharp]
----

public void SendMessageAsParameter(ParameterObjectMessageSender sender)
 {
     sender.Send(new SendMessageRequest()
     {
         Text = "the message body",
         Receiver = "PARTNER001",
         Sender = "PARTNER002"
     });
 }
----

As Jeremy points out:

____
this third incarnation of the API reduces errors in usage with much simpler mechanics than the fluent interface version.
____

You need much less code to get the second version to work which my colleague Lu Ning pointed out to me when we were discussing http://www.markhneedham.com/blog/2009/08/15/builders-hanging-off-class-vs-builders-in-same-namespace/[how to use the builder pattern] on a project we worked on together.

In general terms the benefit of using object initializer is that we get more expressive code and the intent of that code is clearer than we would be able to achieve by constructing the object using its constructor.

The down side is that it creates a mentality of using setters and the initialisation of the object potentially leaves several fields with null values.

We then end up either getting unexpected null reference exceptions throughout the code or we code defensively and check for nulls whenever we try to access one of the properties. Seeing as one of the goals of the object initializer is to reduce the code we write it's somewhat ironic that we end up writing this extra code to ensure the object has been setup correctly.

One way to solve this is to make use of http://www.markhneedham.com/blog/2009/03/10/oo-micro-types/[tiny types] so that the API is still expressive even though what we want to pass in is a string. That takes more code but it allows us to make use of the constructor to construct the object which is something which seems to have lost favour.

C# 4.0 will introduced http://geekswithblogs.net/michelotti/archive/2009/01/22/c-4.0-named-parameters-for-better-code-quality.aspx[named parameters] into the language which seems like it will help us achieve expressiveness of our code without having to write extra classes and code to achieve this.

* Updated the examples as I had them the wrong way around. Thanks to Corey Haines and Mike Wagg for pointing it out.
DDD8: Mixing functional and object oriented approaches to programming in C#
Date: 2010-01-31 14:05:05

I did a presentation titled 'Mixing functional and object oriented approaches to programming in C#' at the http://developerdeveloperdeveloper.com/ddd8/Schedule.aspx[Developer Developer Developer conference] in Reading.

The slides from the talk are below:

http://www.slideshare.net/markhneedham/mixing-functional-and-object-oriented-approaches-to-programming-in-c[Mixing functional and object oriented approaches to programming in C#]

I've not done many technical talks so far. My only previous attempt was a talk on http://www.markhneedham.com/blog/2009/06/30/f-what-ive-learnt-so-far/[F# one at the Sydney Alt.NET user group] last year so I'm still learning how to do this effectively.

It was quite interesting reading through some of the feedback from twitter and several people pointed out that the content was too basic which was something I was concerned about while writing the talk:

____
OK. 30 mins into #ddd8 talk of functional vs OO approaches and I've been told one small thing I didn't know.
____

____
#ddd8 finished @markhneedham talk\... Good speaker,but but basic For me, the last 20% of the content should have been 80% of the talk
____

____
"If you want to learn more\..." Er\...yeah. I certainly want to learn more than I just did. #ddd8
____

____
Mark did a good job but difficulty lvl would help as it was quite basic. Missed caching bit looking at twitter. Doh!
____

____
Mark Needham's talk on functional and OO at #DDD8 was OK, but the first 2/3 was too much of a simple intro.
____

The feedback I got in person was that the talk worked alright and there were a couple more positive comments on twitter too:

____
Great day at #ddd8 - really enjoyed Mark Needham's functional programming session & testing ASP.Net with Ruby
____

____
Listening to @markneedham at #ddd8. He has a fantastic abilty to break things down and explain them :)
____

I think there were probably too many slides in the talk - I found myself pausing unnaturally so that I could move to the next slide which was also pointed out on twitter:

____
In my first session at #ddd8 on functional programming - loadsa slides - someone get the guy a remote!
____

I think I'll probably go with less slides the next time - some of them weren't adding much value anyway so I don't think it would hurt too much to drop them.

Overall though it was a good experience for me getting the chance to put this talk together and I think I learnt a little more about better ways to understand the way we can use functional programming in C# by having the opportunity to prepare this.
TDD: Hungarian notation for mocks/stubs
Date: 2010-01-06 00:08:14

A fairly common discussion that I've had with several of my colleagues is around the way that we name the variables used for mocks and stubs in our tests.

There seems to be about a 50/50 split between including 'Stub' or 'Mock' on the end of those variable names and not doing so.

In a simple example test using Rhino Mocks as the testing framework this would be the contrast between the two approaches:

[source,csharp]
----

[Test]
public void ShouldDoSomething()
{
	var someDependency = MockRepository.CreateMock<ISomeDependency>();

	someDependency.Expect(x => x.SomeMethod()).Return("someValue");

	var myController = new MyController(someDependency);
        myController.DoSomething()

	someDependency.VerifyAllExpectations();
}
----

[source,csharp]
----

[Test]
public void ShouldDoSomething()
{
	var someDependencyMock = MockRepository.CreateMock<ISomeDependency>();

	someDependencyMock.Expect(x => x.SomeMethod()).Return("someValue");

	var myController = new MyController(someDependencyMock);
        myController.DoSomething()

	someDependencyMock.VerifyAllExpectations();
}
----

I favour the former where we don't specify this information because I think it adds unnecessary noise to the name and is a detail about the implementation of the object behind that variable which I don't care about when I'm reading the test.

I do care about it if I want to change something but if that's the case then I can easily see that it's a mock or stub by looking at the place where it's instantiated.

From my experience we often tend to end up with the situation where the variable name suggests that something is a mock or stub and then it's used in a different way:

[source,csharp]
----

[Test]
public void ShouldDoSomething()
{
	var someDependencyMock = MockRepository.CreateMock<ISomeDependency>();

	someDependencyMock.Stub(x => x.SomeMethod()).Return("someValue");

	var myController = new MyController(someDependencyMock);
        myController.DoSomething()
}
----

That then becomes a pretty misleading test because the reader is unsure whether the name is correct and the stub call is incorrect or whether it should in fact be a stub and the name is wrong.

The one time that I've seen that extra information being useful is when we have really long tests - perhaps when writing tests around legacy code which is tricky to get under test.

In this situation it is very nice to be able to  easily see exactly what we're doing with each of our dependencies.

Hopefully this is only a temporary situation before we can work out how to write simpler tests which don't require this extra information.
Coding: The collecting parameter pattern
Date: 2010-01-23 14:45:59

The http://www.industriallogic.com/xp/refactoring/accumulationToCollection.html[collecting parameter pattern] is one of my favourite ones when used well but I've noticed recently that it can lead to quit misleading APIs as well.

One way that we used it quite effectively was when http://www.markhneedham.com/blog/2009/03/10/oo-micro-types/[getting objects to render themselves to a ViewData container] which was then used to populate the view.

[source,csharp]
----

public class Micro {
	private string micro;

	public Micro(string micro) {
		this.micro = micro;
	}

	public void renderTo(ViewData viewData) {
		viewData.add(micro);
	}
}
----

I think it's quite obvious from the method name what it does and we can easily test this method by checking on the contents of the value passed in after the method's been executed.

The problem I've noticed with this pattern is when the method isn't so explicit about what it's doing or where a method is using a collecting parameter as well as returning a value.

For example:

[source,csharp]
----

public SomeModel GetModel(ViewData viewData)
{
	viewdata["someKey"] = "someValue;
	// do some other stuff

	return new SomeModel(...);
}
----

It's not entirely obvious from reading the method signature that it would be mutating the 'ViewData' that's been passed in. I would actually expect that 'SomeModel' is being constructed from 'ViewData' if I just read the method signature in isolation. It's almost like it's following the collecting parameter pattern by accident.

In a way I find that API as misleading as ones which make use of an 'out' parameter to allow multiple values to be returned - it doesn't do what you expect, its *intent is not clear*.

Since I've started playing around with functional programming languages I've become more keen on the idea that functions take in inputs and return outputs and this pattern goes against that idea by encouraging mutation of state.

It seems to me that for the most part writing functions which return a value and don't do anything else reveal their intent more and for the less frequent occasions where we want to keep encapsulation but still find out some data about an object the collecting parameter pattern works pretty well. It should be used sparingly though.
TDD: Rewriting/refactoring tests
Date: 2010-01-25 22:06:23

I've read several times about the dangers of http://chadfowler.com/2006/12/27/the-big-rewrite[the] http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky[big] http://www.magpiebrain.com/2010/01/10/the-great-rewrite/[rewrite] when it comes to production code but I've recently been wondering whether or not we should apply the same rules when it comes to test code or not.

I worked with http://raphscallion.com/blog/[Raphael Speyer] for a few weeks last year and on the code base we were working on he often spent some time rewriting tests originally written using http://rmock.sourceforge.net/[rMock] to use http://mockito.org/[mockito] which was the framework we were driving towards.

One of the benefits that he was able to get from doing this was that he had to understand the test in order to change it which enabled him to increase his understanding of how the code was supposed to work and identify anything that didn't seem quite right.

I quite liked this idea at the time and while spending some time recently working with some tests which required quite a lot of setup and were testing several different things in the same test.

Unfortunately a few of them were failing and it was quite difficult to work out why that was.

My initial approach was to try and work my way through the tests inlining all the test code to start with and then http://www.markhneedham.com/blog/2010/01/24/tdd-removing-the-clutter/[extracting out irrelevant details] to make the tests easier to understand.

Despite those attempts I was unable to work out why the test was failing so I worked out what the main things the test was trying to verify and then wrote tests from scratch for each of those cases.

I was able to write tests covering everything the original test did in several smaller tests in less time than I had spent trying to debug the original one and with a fair degree of confidence that I'm testing exactly the same thing.

As I see it the big danger of rewriting is that we're always playing catch up with the current system which is still being worked on in production and we never quite catch up.

I'm not so sure this logic applies in this case because we're only rewriting small bits of code which means that we can replace the original test very quickly.

My main driver when working with tests is to ensure that they're *easy to understand* and make it *easy to reason about the code* so if I have to rewrite some tests to make that happen then I think it's a fair trade off.

My initial approach would nearly always be to refactor the tests that are already there. Rewriting is something I'd look to do if I was really struggling to refactor effectively.
TDD: Simplifying a test with a hand rolled stub
Date: 2010-01-25 21:23:31

I wrote a couple of weeks ago about my thoughts on http://www.markhneedham.com/blog/2010/01/15/tdd-hand-written-stubs-vs-framework-generated-stubs/[hand written stubs vs framework generated stubs] and I noticed an interesting situation where it helped me out while trying to simplify some test code.

The code in question was making use of several framework generated stubs/mocks and one in particular was trying to return different values depending on the value passed as a parameter.

The test was failing and I spent about half an hour unsuccessfully trying to work out why it wasn't working as expected before I decided to replace it with a hand rolled stub that did exactly what I wanted.

This is a simplified version of the test:

[source,csharp]
----

[Test]
public void SomeTest()
{
	var service = MockRepository.GenerateStub<IService>();

	service.Stub(x => x.SomeMethod("call1")).Return("aValue");
	service.Stub(x => x.SomeMethod("call2")).Return("anotherValue");

	// and so on

	new SomeObject(service).AnotherMethod();

       // some assertions
}
----

For the sake of the test I only wanted 'service' to return a value of 'aValue' the first time it was called and then 'anotherValue' for any other calls after that.

I therefore wrote the following hand rolled stub to try and simplify the test for myself and plugged it into the original test:

[source,csharp]
----

public class AValueOnFirstCallThenAnotherValueService : IService
{
	private int numberOfCalls = 0;

	public string SomeMethod(string parameter)
	{
		if(numberOfCalls == 0)
		{
			numberOfCalls++;
			return "aValue";
		}
		else
		{
			numberOfCalls++;
			return "anotherValue";
		}
	}
}
----

[source,csharp]
----

[Test]
public void SomeTest()
{
	var service = new AValueOnFirstCallThenAnotherValueService();

	new SomeObject(service).AnotherMethod();

       // some assertions
}
----

I've never tried this particular approach before but it made it way easier for me to identify what was going wrong and I was then able to get the test to work as expected and move onto the next one.

In retrospect it should have been possible for me to work out why the original framework generated stub wasn't working but it seemed like the right time to cut my losses and the time to write the hand generated one and get it working was an order of magnitude less.