# Friday, 22 July 2016

I started using Microsoft Fakes for some code I was not able to encapsulate and use Interfaces for (my preferred approach) . One of the issues I had was the documentation didn’t appear to be all that good compared to the wealth of information available for RhinoMocks and MOQ especially around Instance methods.

Here is my scenario. I was calling an external class from my code and wanted to test some code that handled an error if the code was called on the second attempt. In Rhino Mocks or MOQ this type of expectation was very easy to code but with Microsoft Fakes the majority of examples appeared to be around static methods.

I knew you could use the AllInstances method for all Instances however I was not clear how I could have an instance do something different when called the next time. My approach was to store the amount of times it was called in a variable and then do something based on that variable count.

Anyway to cut a long story short here is my approach.

    using (ShimsContext.Create())
    {
		int shimCalled =0;
		
		ShimExternalServiceHttpClientBase.AllInstances.GetTransactions =(x,y,z)
		=> 
		{
			shimCalled++;
		    if(shimCalled==1)
			{
				 return Task.FromResult(new List<TransItem>() {new TransItem() {Id = 99}, new TransItem() {Id = 33}});
			}
			
			return Task.FromException<List<TransItem>>(new TransException());
		}
		
		var transcalculator = new TransCalculator();
		
		var results = transcalculator.CalculateResultsForBatch(1);
		
		Assert.AreEqual(2,results.Count);
		
	}

This approach works well for me. Basically on the first call I want data to be returned and on the second call I want to raise an error to check that my code can handle this type of error correctly.  I must also point out that this method I am shimming uses async calls hence the Task.FromResult and Task.FromException being used.

I am not entirely sure if the above is the best approach to use however I was unable to find another way I could use an instance method in this way.



.
Tags: Shims | TDD | Visual Studio

Friday, 22 July 2016 17:09:08 (GMT Daylight Time, UTC+01:00)  #    Comments [0]


# Friday, 05 December 2014

I’ve recently completed a project working with a great development team. Every time you work on a new project even in a software coaching role you hope people learn new things from you and that you also importantly learn new things from them. 

One of the things I found interesting was getting the team to follow Test Driven Development. The reason I was so adamant about it even down to being called “Mr Test” by the team, is that I like many other developers have been on projects where any kind of automated testing had been thrown out of the window or not been given the attention it deserves. All too many times teams have said they are following test driven development and not really know what it actually means. You may have heard the following.

  • “Its only a small change there’s no need to test it”
  • “I’ll write the tests later I just want to get it done.”
  • “I’ll put a task in the backlog to write the tests”
  • “I’ll write the code and you write the tests”

TDD aside, I think the first thing that has to be understood, is why unit testing is actually important. This is the example I like to use. When we build our application, its a bit like building a house, you need to ensure you have good strong foundations before you start building those brick walls. Software development is very similar in the example below our foundation is the code we have previously written and to ensure this code does what it is supposed to we protect what we have previously done with unit tests.

Our tests are our insurance policy. They ensure that our code behaves the way it was intended long after we have left it and moved along to the next piece of development.

image

Just like building the foundations of a house you don’t necessarily realise the consequences of doing it incorrectly until later. Unit testing is very much the same, its not until later that you realise your application is falling apart and you have absolutely no idea why. Every change you make to the application fills you with dread because you have no idea what you will end up breaking next. It can also be one of the reasons a team starts off with a high velocity and then suddenly slows down and stops delivering each sprint. 

When teams start to understand the picture above, the rest usually comes together quite easily. Developers start to realise that even if they are working alone in a team of one on some internal code the value of unit testing still applies to them.

TDD should then be a natural extension after the value of unit testing is fully grasped. Test Driven Development helps us think about the intent of our code, how we are going to test our application upfront, it makes us think about the design and can encourage good design at the same time.



.
Tags: Agile | TDD

Friday, 05 December 2014 12:41:17 (GMT Standard Time, UTC+00:00)  #    Comments [0]