The myth of integration tests

Eli Lopian    Agile, TDD    

The question of what exactly is a unit test, is one that keeps on plaguing us as a community. I have heard many developers say “oh, no need to test that – its an integration test”.

Well – what is a unit test? and what is an integration test? Guess what: One programmer’s unit test is another’s integration test.

I have talked before about Microsoft getting it right when they called their developer testing tool msTest and not msUnit, and I am going to continue that line of thought. Most developers call any tests that is too complex to automate an Integration test. e.g. GUI or Database. The truth is once the right tools are in place and these ‘impossible to test’ will be possible, and once they are possible – they will be called unit-tests.

So all the tests that we can automate are unit-tests and those that are too complex to automate are integration tests. The complexity can come from brittleness of the tests – so when developing database applications – relying on the actual database will make our test brittle – i.e. Integration test.

We will see in time that with the right tools, we will have more areas that will be called unit tests, because testing them will become easy.

Isolator for SharePoint – Free License

Eli Lopian    .NET Tests, Product, Release, SharePoint    

Get a free Typemock Isolator license:

[Update: Contest is finished, Thanks to all you bloggers]

We’re announcing today about a new product: Isolator for SharePoint. It is almost the same as Typemock Isolator, but will only work on APIs that are directly connected with sharepoint’s API. That means that if you only need to test sharepoint stuff, you can get a powerful product, for a much cheaper price than the full Isolator (you can always upgrade later if you need to isolate more APIs).

With this release, we want to gather the power of crowds, by offering you an incentive for blogging about this news: Get A free Typemock Isolator license (the full one) just because you have a blog. Here’s the official word:

Are you a blogger, webmaster, or Internet columnist? Get a Free Typemock Isolator License (Personal Edition) by helping us launch our new product, Isolator For SharePoint, the only tool that can unit test SharePoint applications without a SharePoint server – see the Microsoft Guidance.

Go ahead, post about it now and your Free License will be on its way!

So how do I get the Free License?

Just make a post on your blog or site about the latest Typemock product, that includes the following text:

Typemock are offering their new product for unit testing SharePoint called Isolator for SharePoint, for a special introduction price. it is the only tool that allows you to unit test SharePoint without a SharePoint server. To learn more click here.

The first 50 bloggers who blog this text in their blog and tell us about it, will get a Full Isolator license, Free. for rules and info click here.

Then please send an email to sharepoint@typemock.com including your name and the post URL, and your Free License will be on its way!

Hurry up – this offer is limited to the first 50 bloggers.

A few simple requirements:

(1) You must own a website, blog space or internet column, older than 2 months, or get permission from the owner of such a site.
(2) Your post must include the text above (including the links).

Team building

Eli Lopian    Management for Geeks    

Once when I was working for a large enterprise, we where taken  to an off-site team building program. We where divided into groups of 5 and the group had a task of creating 5 squares out of paper cuttings of different shapes and sizes. Each team-player got a few pieces and the rules where:

1. No talking
2. You can only give a piece (no taking)
3. The game ends when every player has a complete square

The trick in this session was that one team-player got just the right amount of pieces to make a rectangle, that team-player would finish his rectangle and then just leave the game feeling that he finished his part. In may cases the team-player would physically leave and go have a coffee or just to chat with other ‘rectangle’ team-players (normally boasting how they finished first not even considering the fact the they don’t have a square but a rectangle).

The point is that the team as a whole cannot finish its task. In order for every team-player to have a square the rectangle must be dismantled by the ‘rectangle’ team-player (as no-one can take any piece only give) and give away some of his pieces. It normally takes the team a few minutes to understand this but as they cannot talk between each other – they are in a deadlock. The ‘rectangle’ team player is sure that he has finished the task and has switched off, no one is allowed to talk or touch his pieces and most of the time the ‘rectangle’ team player is no where to be found. (Bonus: How can you break this deadlock)

The lesson learnt is that although you think that you have done your job – it might not help the team as a whole to complete their job, you might even delay them!

Although one development team are sure that by using the best process (Agile) they have done there job, they might be delaying the rest of the teams and the company as a whole.

The solution is in Communication. More about that later.

Back to School

Eli Lopian    Uncategorized    

One of the delights of being an adult is the fact that you can practically wake up at any time you want. When I was in school I really disliked waking up in the morning to go to school. Now that my oldest daughter is in school – I have to get her ready for school and so I have to both wake up on time and try to wake her up. But having a child in school does have its perks. Last week I volunteered to give the class an hour and teach them origami. Here are some pictures from the schools blog where we created butterflies and frogs Next time I might teach them some C# and how to unit test…

Unit Testing Collections

Eli Lopian    .NET Tests, TDD    

I have written about Lowering the friction of Unit testing, and how using Aspect Faking we can lower the friction of testing collections

The problem

Unit testing collections can be a bit tricky. Lets see some code and unit test this Sum() method:

public List<Salary> Salaries { get; }

public float Sum()
{
    float total = 0;
    foreach (var item in Salaries)
    {
        total += item.Value;
    }
    return total;
}

public class Salary
{
    public float Value { get; set; }
    ...
}

Testing this can be simple: just supply a collection with fake items and run the code.

[TestMethod]
public void Sum_Adds3Items()
{
    var fakeSalaries = new List<Salary> {

        new Salary { Value = 5000 }, 

        new Salary { Value = 6000 }, 

        new Salary { Value = 5500 } };

    var payments = new Payments();

    payments.Salaries = fakeSalaries;

    Assert.AreEqual(16500, payments.Sum());
}

Simple, but in some cases, it is impossible to create the fake list. Examples are: Linq queries, SharePoints SPListCollection and SPItemCollection and DevExpress XPCollection. This are all custom collections and cannot be instantiated. We want to fake these collections, but we want to do it in a resilient way. Resilient enough that if we can choose to implementation via direct calls on the index without failing our tests.

public XpCollection<Salary> Salaries { get; set; }

...

float total = 0;

for (int i = 0; i<Salaries.Count; i++)
{
    total += Salaries[i].Value;
}
return total;

Here is where Faking the Collection Aspect comes into play, we want to fake just the Collection-Aspect the XpCollection and swap it with a collection of our choice.

Isolate.Swap.CallsOn(payment.Salaries).WithCallsTo(
   new[] {
        new Salary { Value = 5000 },
        new Salary { Value = 6000 },
        new Salary { Value = 5500 }
   });

Isolate.WhenCalled(() => payment.Salaries)
   .WillReturnCollectionValuesOf( new[]
   {
        new Salary { Value = 5000 },
        new Salary { Value = 6000 },
        new Salary { Value = 5500 }
   });

Crypt message in the Blog

Eli Lopian    Uncategorized    

Someone is writing crypt messages in my Blog.
Might it be from Aliens or a Conscious Robot?

1,2,3,4,5,6,7,8

Estimations and being Agile

Eli Lopian    Agile, Management for Geeks    

There are quite a lot of information in the web about how to  estimate tasks in an Agile environments – They are all based on dividing the task to small features and using a statistical technique to estimate the time. But these are quite complex and take allot of resources from the team, and at the end of the day are not exact anyway. Are we wasting our time? Could there be another way?

We already know that we will never really know how long the task will take until we finish it and that we are always estimating anyway. That is why in Agile-Processes we have two estimations – one is a highlight of what can go in a release and the other is per iteration. Still when management asks a simple question – How long will it take to add a feature – the team is stunned and requires several hours to try to understand the domain and come up with an answer that is not exact anyway.

In many companies, it is considered most important to be on time. Soo important that everyone is afraid to be late. Because of this when asked – When can you finish a feature, we will do one of the following:

1. Say: We need to know EXACTLY what user stories are included in this feature so that we can have a planning session to give you the answer.

2. Guestimate and add a huge buffer – make sure that there will be no way that we will be late.

Both are bad for the company – the first requires us to do an up-front ‘design’ in order to get the estimate – wasting time, as we might not even implement the feature. The other gives wrong numbers and might lead to the company making the wrong choice.

Estimating and Event Driven

I wrote before about Improving Agile Development by Event-Driven Management. This is going to be a third option.

3. Understand that it is alright to be late as long as you raise the event early enough. Once we reach that understanding we can be more agile and waste less. We can give the management an estimation – one that we really think is correct (we should still reduce the known features to smaller one- but we will still have many unknowns) , and down the line, the moment that we understand the we won’t be on time – raise the event – and tell the management so – as early as possible to allow the company to deal with it. 

Just like the meeting in the previous post, if we are to meet someone in an foreign location, we can still set up a time, work backwards to see more or less when we have to leave and try to get there on time.
Many things can happen on the way, but as long as you tell the other party that you are going to be late as early as possible. It should still be ok.

So we can waste less time in the estimation/planning/release meetings, do a simple estimation and get on to do the work. If we understand that we are not going to make it on time – simply inform everyone.

Doing this allows us to have to courage to give the estimation that we believe without requiring all the information. It also allows us to make a mistake and be late – as long as we communicate this on time.

Lowering the friction of Unit testing

Eli Lopian    .NET Tests, TDD    

At Typemock we have been learning allot about our customers lately and understanding where the friction is so that we can make unit testing even easier and maintainable.

What we are succeeding in doing is to lower the density of the tests (this means less code in each test) and raise the test resilient (this means the tests will still work after code changes)

Roy Oserove has talked about this (here, here and here). This has been the basis for the new API and concepts that we have already introduced in Typemock Isolator.

One feature that does this is the Recursive Fakes. Using this we fake and ignore a whole component, by faking a complete call stack. Our classic example is using SharePoint. In SharePoint a top most entry point is SPSite(). All other operations are a part of the call stack and objects returned from the SPSite.

example:

    var site = new SPSite();
    var web = site.OpenWeb();
    var lists = web.Lists;
    var items = lists[1];
    items[2].Update();

Note that SPSite is a Mother class of all other types.

We found out that in our tests, we normally don’t want to fail if any extra calls are called within this call stack. We also still want the test to pass if less calls are made within the call stack. Here is how we do it:

SPSite fakeSite =
   Isolate.Fake.Instance<SPSite>(Members.ReturnRecursiveFakes);

Using this will fake ALL the methods above, and all other methods that are called on the call stack of fakeSite! We can of course specify a fake value down the call stack:

Isolate.WhenCalled(
 () => fakeSite.OpenWeb().Lists[2].Items[1].Update).
 WillThrow(new Exception("");

Here we simulate an exception down the call stack, but all other calls will just work!

Thinking in the terms of Faking the call stack helps in writing less code in the test and adding to the resilient of the test. We are going to keep that trend as we continue to promote unit testing by enabling easy isolation.

Typemock embraces SharePoint

Eli Lopian    .NET Tests    

We have been getting a lot of traction from the SharePoint development community about the ease that Typemock Isolator helps unit test SharePoint Applications.

The Practices and Patterns Group in Microsoft have released a SharePoint Guidance that you can download the November 2008 version here. Typemock Isolator is being used as the primary isolating tool.

We are getting many great comments, here are some of the stuff we are getting

• Typemock embraces SharePoint – Andrew Woodward
• Typemock SharePoint wrapper – open source, by Carlos Segura
• Francis K. Cheung blog - Unit testing SharePoint 2007 applications
• Swapping Collections with Typemock Isolator – Typemock’s Blog
• I’m in love with the new Typemock Isolator release… finally we can write unit tests against the SharePoint OM that are not brittle WOOT! – Twitter

We are planning in creating a special package for SharePoint developers. Wait for the news on our SharePoint page

Ruby Style Isolating – Aspect Faking

Eli Lopian    .NET Tests, Product, TDD    

I have talked in the past about Ruby Style Isolating (Dynamically Typed), now it is part of the AAA syntax. 

The big value of this feature is that you don’t have to inherit a type in order to replace it with a fake, the downfall of this is that when you refactor your code, you might fail the test.

There are many uses. One example is if you have a class without virtual methods,  you can still overload it and swap the real type with the fake one.

This gives you testability strengths and the ability to keep your design intact.

Example Suppose we have the following class:

public class NiceClassWithoutVirtual
{
    public int NonVirtualMethod()
    {
        return 30; // an example not virtual
    }
}

Now we want to use a manual Stub to replace our NonVirtualMethod: we can do the following: note the new before the method.

public class FakeNiceClass: NiceClassWithoutVirtual
{
    public new int NonVirtualMethod()
    {
        return 2; // our fake value in new not virtual method
    }
}

We can use the Stub as follows

var real = new NiceClassWithoutVirtual();
var fake = new FakeNiceClass();
Isolate.Swap.CallsOn(real).WithCallsTo(fake);

All real.NonVirtualMethod() calls will be directed to fake.NonVirtualMethod()

Fake an Aspect

Note that any methods that are not defined in the swapped type will be run as normal. This allows ‘Aspects’ of the original class to be faked. It is possible to fake a group of methods that have a specific meaning, for example just the ISerializable aspect or just the IEnumerable aspect – so we can fake the collection behavior aspect of a type. This is exactly how we implemented the Swap-Collections Feature.