Helper Code

How to write a unit test

noreply@blogger.com (Dror Helper) — Wed, 15 May 2013 19:35:00 +0000

Last week I had the pleasure of participating in Sela Developer Practice.
Before my session I sat through Gil ZIlberfeld’s session “7 steps for writing your first unit test” and I found myself thinking – what are steps I take when writing a new unit test?
I’ve been writing them for so long and never noticed I’ve been following a “methodology” of sort. And so without further ado – here is the steps I take when writing a new unit test:

The code under test

In order to write a unit test I’ll need an example and so I came up with the following scenario:

This is the latest and greatest bug tracking software and we need to add a feature – send an email when a bug with certain severity is created.

The code we want to test looks something (read: exactly) like this:

public class BugTracker
{
    private readonly IBugRepository _repository;
    private readonly IEmailClient _emailClient;

    public BugTracker(IBugRepository repository, IEmailClient emailClient)
    {
        _repository = repository;
        _emailClient = emailClient;
    }

    public Bug CreatNewBug(string title, Severity severity)
    {
        if (string.IsNullOrEmpty(title))
        {
            throw new ApplicationException("Title cannot be empty");
        }

        var newBug = new Bug
             {
                 Title = title,
                 Severity = severity
             };

        SaveBugToDb(newBug);

        // Here be code        

        return newBug;
    }

And so since we’re avid TDD (Test Driven Design) practitioners we’ll start by writing the test first.

Decide what you’re testing

Although this might sound trivial – deciding what to test is a step that many developers tend to forget - instead they write a chunk of code and assert whatever they can.
I found that naming the test method in such a way that forces me (and my fellow developers) to think about what they are about to do:

[TestFixture]
public class BugTrackerTests
{
    [Test]
    public void CreatNewBug_CreateBugHasHighestSeverity_SendEmailToProjectManager()
    {
        
    }
}

I didn't invent this naming convention but I find it very useful. The name is divided into three parts:

The method I’m testing - not description, scenario just the name of the method
The scenario I’m testing
What I expect to happen

The added benefit is that when this test would fail – all I need is to read the name of the test to know what went wrong – take that F5!
There are other similar naming schemas – choose one and be persistent about it.
So now I know what I’m about to test and the next step is to write exactly that.

Write the method under test

I’m starting from the bare minimum and building my test from the inside out.
First I’ll create the class I’m testing and then I’ll run the method I’m testing.

[Test]
public void CreatNewBug_CreateBugHasHighestSeverity_SendEmailToProjectManager()
{
    var cut = new BugTracker();

    cut.CreatNewBug("my title", Severity.OhMyGod);
}

Unfortunately this does not even compile. The problem is that I need to “feed” the BugTracker class two dependencies of type IBugRepository and IEmailClient – so let’s add them courtesy of an Isolation framework (in this case FakeItEasy):

[Test]
public void CreatNewBug_CreateBugHasHighestSeverity_SendEmailToProjectManager()
{
    var fakeBugRepository = A.Fake<IBugRepository>();
    var fakeEmailClient = A.Fake<IEmailClient>();

    var cut = new BugTracker(fakeBugRepository, fakeEmailClient);

    cut.CreatNewBug("my title", Severity.OhMyGod);
}

And now we can write the actual assertion.

Write the assertion

Since we need to check that our email client has sent a message we need to use the power of our isolation framework to assert exactly that

[Test]
public void CreatNewBug_CreateBugHasHighestSeverity_SendEmailToProjectManager()
{
    var fakeBugRepository = A.Fake<IBugRepository>();
    var fakeEmailClient = A.Fake<IEmailClient>();

    var cut = new BugTracker(fakeBugRepository, fakeEmailClient);

    cut.CreatNewBug("my title", Severity.OhMyGod);

    A.CallTo(() => fakeEmailClient.Send("manager@project.com", "Don't Panic!")).MustHaveHappened();
}

Run the test

Now that we have all the parts placed it’s time to run the test and see it fails.
The test did fail but from the wrong reasons:

It appear I have a code inside the method “SaveBugToDb” that throws an exception:

private void SaveBugToDb(Bug newBug)
{
    if (!_repository.Connected)
    {
        throw new ApplicationException("Cannot access bug repository");
    }

    _repository.Save(newBug);
}

This means going back to the drawing board for us.

Add more code

In order to make the test fail from the correct reason I’ll add one more line courtesy of our Isolation framework to make sure that a call to Connected will always return true:

[Test]
public void CreatNewBug_CreateBugHasHighestSeverity_SendEmailToProjectManager()
{
    var fakeBugRepository = A.Fake<IBugRepository>();
    A.CallTo(() => fakeBugRepository.Connected).Returns(true);

    var fakeEmailClient = A.Fake<IEmailClient>();

    var cut = new BugTracker(fakeBugRepository, fakeEmailClient);

    cut.CreatNewBug("my title", Severity.OhMyGod);

    A.CallTo(() => fakeEmailClient.Send("manager@project.com", "Don't Panic!")).MustHaveHappened();
}

Run the test (again)

No I run the test again and it fails on the assertion. If it wasn’t the case I would go back and add more code to make sure that the test follow the correct path until I’m satisfied that I’m testing the correct thing.

Write the code to make the test pass

This one is simple – just add the code that makes the test pass:

public Bug CreatNewBug(string title, Severity severity)
{
    if (string.IsNullOrEmpty(title))
    {
        throw new ApplicationException("Title cannot be empty");
    }

    var newBug = new Bug
         {
             Title = title,
             Severity = severity
         };

    SaveBugToDb(newBug);

    if (severity == Severity.OhMyGod)
    {
        _emailClient.Send("manager@project.com", "Don't Panic!");
    }

    return newBug;
}

Conclusion

So what did we do:
Decided what to test
Write the method under test
Add assertion
Run the test
Add more code
Repeat steps 4,5 if necessary
Write the code that makes the test pass

A few comments before the end:

This is nothing new if you’re been writing unit tests in the past – you’ve probably followed a similar process – I just needed to write is down explicitly.
It seems like a lot of steps just to create a single test? Don’t despair - writing all of them should not take too long and besides – can you write a test without going through all of them in one way or another.
I'm a true believer of writing the tests before the code but don’t worry this method sans step 7 will work even if you write your tests retroactively.

Happy coding…

Sela Developer Practice 2013

noreply@blogger.com (Dror Helper) — Wed, 24 Apr 2013 11:53:00 +0000

I’m speaking at SDP2013 – two weeks from now.

I’ll be talking about mocking (surprise!) in “Battle of the Mocking Frameworks”.

So if you’re happen to come to the conference on May 7th – drop by and say hi.

Until then – happy coding…

Unit testing multi threaded code–Timers

noreply@blogger.com (Dror Helper) — Tue, 26 Mar 2013 21:01:00 +0000

Writing unit tests for multi-threaded is not simple and could even be impossible for some scenarios – how could you test that an asynchronous method was not called?
Since most unit testing examples tend to be rather trivial I’ve decided to try and explain other more complex scenarios – preferably without using any calculator examples.

The “Timer” problem

Consider the Timer class (or rather classes), .NET has several classes called Timer, In this post I’m referring to System.Threading.Timer and System.Timers.Timer which is built on top of the former.
Both perform an action in another thread (using the Thread Pool) in intervals (not accurately – but I won’t go there in this post).
Consider the following class:

public class ClassUnderTest
{
    private readonly Timer _timer;

    public ClassUnderTest()
    {
        _timer = new Timer(1000);
        _timer.Elapsed += PerformPeriodicAction;
        _timer.Start();
    }

    public ClassUnderTest(Timer timer)
    {
        _timer = timer;
        _timer.Elapsed += PerformPeriodicAction;
        _timer.Start();
    }

    private void PerformPeriodicAction(object sender, ElapsedEventArgs e)
    {
        // Perform very important task here!
    }
}

Testing code that employs timers can be tricky. Unfortunately there’s a tendency to write a test that looks like this when timers are involved:

[Test]
public void TestJustWrong()
{
    var cut = new ClassUnderTest();

    // Make sure the timer executed at least once
    Thread.Sleep(5000);

    // Check that something happens
}

So what is the problem?

Although it might seem like a valid unit test – in fact it’s a test that would fail from time to time - whenever the timer would happen to “tick” for more than the sleep period.
These kind of tests are known as the “the test that tends to fail” and usually “fixed” by running the build script another time.
You do not want a test that you cannot trust to fail only when a bug is introduced into your system.
Sadly I’ve seen this code – a lot! But no more - writing a good unit test for that class is simple, in fact there is more than one alternative that creates a simple, trustworthy unit test.

Solution 1 – invoke the handler instead

Instead of waiting for the time to execute why not call the method that handles the timer’s event?
First we need to make sure that the method we’re going to call is internal or public. I personally don’t like changing my production code that much in order to make the code “testable” but it’s a way.
Now all we have to do is call the method thus making sure that execution happens exactly when we want it – and a unit test is born:

[Test]
public void TestByMethod()
{
    var cut = new ClassUnderTestForTestability();

    // Let's call the method
    cut.PerformPeriodicAction(this, null);

    // Check that something happens
}

Solution 2 – invoke the timer at your leisure

Most modern Isolation (a.k.a Mocking) frameworks have the ability to invoke events as well as create fake objects.
We’re going to create a fake timer and invoke the elapsed event. Using simple constructor injection we’ll pass the timer to our class under test prior to invocation and we have a more robust unit test:

[Test]
public void TestWithFakeTimer()
{
    var fakeTimer = Isolate.Fake.Instance<Timer>();

    var cut = new ClassUnderTest(fakeTimer);

    // Let's invoke the event
    Isolate.Invoke.Event(() => fakeTimer.Elapsed += null, this, null);

    // Check that something happens
}

I’m using Typemock Isolator but you can use the isolation framework of your choice The syntax is strange but once you’ll get used to it, it’s simple.
The added value is that we’re causing the real flow of our program to execute – in a synchronized and timely manner.

Conclusion

Although there are many ways to test code that uses timers I find myself employing the two above most of the time.
I plan to write a few more posts on the other pitfall of testing multi-threaded code (and how to avoid them) but until then –

happy coding…

Spreading the agile joy

noreply@blogger.com (Dror Helper) — Thu, 28 Feb 2013 22:17:00 +0000

I finally hit critical mass!

I got a request from one of the project managers (not my project) to do a quick “introduction to Scrum” session.

It took quite a while – more than two years (and a downsizing) in order for other teams to notice that we have a different way to do things.

I did a very successful session – mainly because the audience “felt the pain”; it was fun explaining about Scrum with examples on how they can utilize it the very next day.

Since I’m not in daily contact with that team – I had no idea how well they implemented Scrum. Until yesterday when I walked on a meeting that had a task board on a big screen – so I guess it went well.

When I was first asked to do this session I wanted to create a simple and short presentation that can be re-used – And here it is:

Introduction to scrum from Dror Helper

It’s simple and short so I use it as a “background” for a discussion on how they are going to use Scrum in their work – today.

I guess I’m doing something right since I have another session next week!

And if you have an agile success story – please share…

Things I learnt reading C# specifications (#1)

noreply@blogger.com (Dror Helper) — Sun, 03 Feb 2013 18:23:00 +0000

After reading Jon Skeet’s excellent C# in Depth - again (3rd edition - to be published soon) I’ve decide to try and actually read the C# language specification…
Being a sensible kind of guy I’ve decided to purchase the annotated version which only cover topics up to .NET 4 – but has priceless comments from several C# gurus.
After I’ve read a few pages I was amazed to learn that a few things I knew to be true were completely wrong and so I’ve decided to write a list of new things I’ve learnt while reading this book.
Below you’ll find a short list of new things I learnt from reading the 1st chapter:

Not all value types are saved on the stack

Many developers believe that reference types are stored on the heap while value types are always stored on the stack – this is not entirely true.
First it’s more of an implementation detail of the actual runtime and not a language requirement but more importantly it’s not possible – consider a class (a.k.a reference type) which has a integer member (a.k.a value type), the class is stored on the heap and so are it’s members including the value type since its data is copied “by-value”.

class MyClass
{
    // stored in heap
    int a = 5;  
}

For more information read Eric Lippert’s post on the subject – he should know.

What the hell is “protected internal”

If you’ve written more than one class you’ve probably used public/internal and protected access modifier:

class MyClass
{
    // Can only be accessed by MyClass
    private object a;

    // Accessible by MyClass and classes that derive from it
    protected object b;

    // Accessible by this assembly
    internal object c;

    // Accessible by everyone 
    public object d;
}

So what does protected internal means?

Some believe that members marked as “protected internal” are only accessible for classes that derive from MyClass AND are defined at the same assembly in fact it means that classes that derive from MyClass OR are defined on the same assembly as my class can access that member. So it’s just like using internal and protected at the same time – confused yet?

Use only immutable types as a readonly fields

How many times have you marked a field readonly?

You probably did it to make sure that a field cannot change after initialization – think again:

class Person
{
    static readonly Person Me = new Person("Dror", "Helper");
}

public void UpdateFail()
{
    // Compilation error!
    Person.Me = new Person("Kaiser", "Soze");
}

public void JustBecauseYouCan()
{
    // This would work!
    Person.Me.First = "Kaiser";
    Person.Me.Last = "Suze";
}

That’s right, while you cannot replace the the readonly field – you can update the heck out of it.

Of course there’s more, I choose these examples because they helped me understand C# better.

I hope to add more such insights as I continue reading the book – so stay tuned…

Happy coding…

Fluent interfaces in C# – Generics

noreply@blogger.com (Dror Helper) — Fri, 11 Jan 2013 14:04:00 +0000

If you haven’t read the previous posts on the subject of fluent interfaces using C# – I suggest you do so now – I’ll wait…

Great! now you’re all ready for the forth post on the subject of using Generics:

Generics were added to version 2.0 of the C# language and the common language runtime (CLR). Generics introduce to the .NET Framework the concept of type parameters, which make it possible to design classes and methods that defer the specification of one or more types until the class or method is declared and instantiated by client code.
[Generics (C# Programming Guide)]

Using generics tor return specific type

If you’ve been programming in C# you’re probably seen generics in the past– either a type safe collection (i.e. List<T>) or written your own generic class/method.
Using Generics in your API is just like saying “of type X” as part of the interface – for example “create a fake/mock of type ILogger”:

// Typemock Isolator
var fakeLogger = Isolate.Fake.Instance<ILogger>();

// Telerik's JustMock
var fakeLogger = Mock.Create<ILogger>();

// NSubstitute 
var fakeLogger = Substitute.For<ILogger>();

Reading the code above you’ll notice something - even if you are not familiar with the topic of mocking frameworks you can still understand what each line does.

The reason that this API is used in mocking frameworks is that they all have something in common – they need to create a new instance of type X - and so they get the type parameter as part of the method call a.k.a generics.

Using Generics to configure action(s) on specific type

If you’re familiar with .NET IoC you might recognize the following API:

Kernel.Register(
   Component.For<ICustomer>()
       .Named("customer")
       .ImplementedBy<CustomerImpl>()
       .Activator<MyCustomerActivator>()
   );

In this example we use generics to configure a component and bind implementation to specific type and use another concrete type to create that instance.

Another example which I use in my project is binding message types to handling method. We have a TCP client (non WCF – what a shame) that returns messages from a single event. Each message type should be handled by a different method (logic).

Using generics and method chaining got us the following solution:

var repo = new MessageHandlerContainer();
repo.Register<ConcreteMessage1>().With(SendEmailNotification)
    .Register<AnotherMessage>().With(SoundAlarm);

// when a message arrive
var newMessage = GetNextMessage();

container.ProcessMessage(newMessage);

Easy to understand what each the code does – without reading the actual implementation.

But just in case – here you go:

public class MessageHandlerContainer
{
    private readonly Dictionary<Type, IMessageHandler> _messageHandlers =
        new Dictionary<Type, IMessageHandler>();

    public void ProcessMessage(IMessage message)
    {
        _messageHandlers[message.GetType()].Run();
    }

    public MessageHandler<T> Register<T>() where T : IMessage
    {
        var messageHandler = new MessageHandler<T>();

        _messageHandlers.Add(typeof(T), messageHandler);

        return messageHandler;
    }
}

The trick in inside the MessageHandler class which adds an action and return the parent container so that you may register yet another message:

public class MessageHandler<T> : IMessageHandler
{
    private readonly MessageHandlerContainer _parent;
    private Action<IMessage> _actionToRun;

    public MessageHandler(MessageHandlerContainer parent)
    {
        _parent = parent;
    }

    public MessageHandlerContainer WithHandler(Action<IMessage> actionToRun)
    {
        _actionToRun = actionToRun;

        return _parent;
    }

    public void Run()
    {
        _actionToRun();
    }
}

It’s not the simplest code to follow – but when you see the usage example (scroll up) you’ll notice it makes a very readable API. Now it’s very simple to add another message handler to the logic without risking spaghetti code.

Conclusion

Generics are very powerful and can be used to in your fluent API to create and register specific types.

There are other uses for generics other than these two but you’ll have to wait for a different blog post – or experiment and find out by yourself.

Happy coding…

nCrunch review – TDD on steroids

noreply@blogger.com (Dror Helper) — Sat, 29 Dec 2012 20:20:00 +0000

Any project that uses unit tests gets to the stage where running all of the tests takes a lot of time. Even if you manage to keep your test suite in a manageable size From time to time a developer would “forget” to run all the tests before commit and break the build.

One solution for these problems is to have an automatic test runner/continuous testing tool that runs the tests automatically.

The idea of continuous testing has it’s roots in the Java world. JUnitMax which was create by Kent Beck, runs all of the tests on each save. The order of the tests is determined by risk – the first tests run were the ones that failed on the previous run. Although this solution does not solve long run times it does make sure that your code is constantly being verified.

In the .NET space there are several such tools one of which shine above the rest - nCrunch.

Getting started

nCrunch is code coverage, test runner and performance analyzer all in one. Using it is simple – all you need to do is to choose to enable it and after filling a few options you’re ready to go.

You can choose how many CPU cores to dedicate to running of tests and whether or not you wish to run your tests in parallel. Another option is to run the test manually – in case you “only” wish to use nCrunch as a test runner.

Running nCrunch

After this short configuration nCrunch would automatically discover all of the unit test in your solution and try to run them. So far I’ve used it with NUnit, and XUnit and it worked perfectly. On each save the code is compiled, and tests are run . nCrunch can be configured to run only the tests affected by the last code change. I’ve used this option thus avoiding a long test run with each change I make.

Another plus is the continuous code coverage results, each line of code written is immediately marked as covered/not covered by unit tests and if that unit test(s) fail – it is also marked in red.

When a test fails nCrunch provide full exception information and an arsenal of debugging options to choose from – from simple “run in debug” to “Break into the first failing covering test at this line”.

Supercharge your unit tests

nCrunch is one of these tools I’ve been looking for without actually realizing it. Using it makes TDD (Test Drive Development) easy to follow. If you want an excellent example – take a look at this video (YouTube):

Around 1:10 it really gets interesting when the code is written and the tests are executed side by side

Conclusion

nCrunch is not the only continuous testing tool out there but it’s certainly the most mature one – with easy configuration and many useful features it’s the unit testing productivity tool that I was look for.

Serialization and events in C#

noreply@blogger.com (Dror Helper) — Wed, 19 Dec 2012 19:45:00 +0000

Today I had an interesting problem:
I was trying to serialize and object using BinaryFormatter but it kept on failing because some class was not Serializable. I’ve double and triple checked my class and all of it’s inner properties and verified that indeed they were marked correctly.

The Problem

Looking closer at the exception I’ve noticed something – the problematic class that was causing me grief was not part of the class. In fact the problematic class was signed to an event of the class I was trying to serialize. SO I had the following code:

var myObj = new SerializableClass();

var notSerializble = new NotSerializableClass(myObj);

IFormatter formatter = new BinaryFormatter();

using (Stream stream = new MemoryStream())
{
    formatter.Serialize(stream, myObj);
    
    ...
}

And the the class – NotSerializableClass was something like this:

public class NotSerializableClass
{
    private SerializableClass myObj;

    public NotSerializableClass(SerializableClass myObj)
    {
        myObj.someEvent += HandleSomeEvent;

        ...

And so the fact that it was attached to the event from my perfectly serializable class caused the problem – the BinaryFormatter was trying to serialize it as well!

The Solution

Once I understood the problem the solution was simple – I’ve marked the event as field:NonSerialized and the problem was solved:

[Serializable]
public class SerializableClass
{
    [field:NonSerialized]
    public event EventHandler someEvent;
}

Simple – as long as you know what to look for.

Agile might save your job

noreply@blogger.com (Dror Helper) — Tue, 04 Dec 2012 20:56:00 +0000

Imagine this: you have two employees, both are hardworking and bright.

You have complete knowledge of what the first employee does, which task he’s working on and its deadline while you have absolutely no idea what the other employee does. While the first employee shows progress every few weeks with new release, the other commits to quarterly plan. The first employee give you daily progress report and notify in advance when he’s going to miss a deadline or a feature.

Now imagine that you must fire one of your employees – which would you choose?

Truth be told most managers prefer employees that shows progress and keeps them well informed.

So how can one protect his job – simply by making sure that his manager and manager’s manger are aware of the state of the tasks under his responsibility and if a deadline is going to be missed – be notify about it as soon as possible – because no manager loves surprises as far as his project is concerned.

The thing is that all of this and more is part of several agile methodologies. It does not matter if you practice SCRUM, Kanban or Lean notifying your manager and tracking progress is an integral part of the process used.

It also helps that following agile methodologies would guarantee that progress is always seen – one iteration after the other.

And the moral of this story (as you might have guessed) is that the Agile team was not fired and they get to do at least one more iteration.

Just a thought…

Making string based method strongly typed

noreply@blogger.com (Dror Helper) — Mon, 05 Nov 2012 20:05:00 +0000

I can't believe they implemented this way – was the first thought on my mind…
The method in question is part of the new(er) NUnit’s constraint based model specifically the one used to assert a property value.
Before we dive deeper a few words on the constraint based model:

constraint based model

Most unit testing framework have similar way of writing assertions – if you’ve wrote a test in the past it probably looked something like this:

Assert.AreEqual(4, 2 + 2);

NUnit has another API for assertion which is more to my liking and using it for the above assertion would look like this:

Assert.That(2 + 2, Is.EqualTo(4));

Using this API I can write pretty cool things:

// Simple values
Assert.That(someInt, Is.Negative);
Assert.That(someString, Is.Not.Null.And.Not.Empty);
Assert.That(someObject, Is.Null);

// Collections
Assert.That(someList, Is.Not.Empty);
Assert.That(intArray, Is.All.GreaterThan(10); // All intergers in array are bigger than 10
Assert.That(array, Has.Exactly(1).GreaterThan(3)); // Exactly one item bigger than 3
Assert.That(someEnumerable, Is.All.Property("MyProp").EqualTo(25));

I have an issue with the last line. I don’t like writing string based code – mainly it tend to break on trivial refactoring and writing assertion that could break on runtime just because someone has changed the property name seems just wrong.
I have as compiler and I’m not afraid to use it – the least you can do is give me compile time errors!

The solution

I’ve wanted to add another method to Is.All and so I’ve used one of fluent API writers friend – the extension method and I got the following API:

Assert.That(someEnumerable, Is.All.Property<MyType>(m => m.MyProp).EqualTo(25));

Using black lambda tricks I was able to create a strongly typed API that receive a property.

After I had my entry point sorted out all I needed to do is write (and copy shamelessly) some cool Expression based code to get the property name and it works!

Here is the full code:

public static ResolvableConstraintExpression Property<T>(
  this NUnit.Framework.Constraints.ConstraintExpression expression,   Expression<func<T, object>> lambda)
{
    MemberExpression memberExpression = null;
    switch (lambda.Body.NodeType)
    {
        case ExpressionType.Convert:
            // lambda is obj => Convert(obj.Prop) - the operand of conversion is our member expression
            var unary = lambda.Body as UnaryExpression;
            if (unary == null)
            {
                Assert.Fail("Cannot parse expression");
            }
            memberExpression = unary.Operand as MemberExpression;
            break;

        case ExpressionType.MemberAccess:
            // lambda is (obj => obj.Prop) - the body is the member expression
            memberExpression = lambda.Body as MemberExpression;
            break;

        default:
            Assert.Fail("Cannot parse expression");
            break;
    }

    if (memberExpression == null ||  string.IsNullOrEmpty(memberExpression.Member.Name))
    {
        Assert.Fail("Labda body is not MemberExpression - use only properties");
    }

    var propertyName = memberExpression.Member.Name;

    return expression.Property(propertyName);
}

I hope it would help at least one reader who cannot accept a string based API.

Happy Coding…

Unit level BDD using SubSpec

noreply@blogger.com (Dror Helper) — Fri, 02 Nov 2012 08:23:00 +0000

In the BDD (Behavior Drive Development) there are two groups of frameworks. The first group contains tools such as SpecFlow and nBehave to name a few all of which uses (at least) two files – one contains the scenarios/behaviors in plain English (more or less) and the other the code that makes it all happen.
I want to discuss the other type – the one that contains “unit level” BDD. Unlike the first group the behaviors are written inside the code where only us developers can read them – you can always try to convince your product/marketing manager to read your code but it tends to go downhill from there…
The reason I’m telling you this is that this week I discovered a very interesting tool – SubSpec. It uses extension methods on System.String, lambdas and some nifty XUnit tricks to make BDD accessible and easy to use.

Getting started

Using SubSpec is simple. After creating a new project add a reference to SubSpec using NuGet:

Adding SubSpec via NuGet will also make sure that you have the required dependencies - XUnit and XUnit.Extensions:

And you’re ready to go…

Writing the first behavior

Like any other test SubSpec test is divided into three parts – Context, Action and Verifications.
The entry point to all three is a string.
Writing a new test is done by following these four steps:

Add Specification attribute to the test method
Use Context to initialize the class under test
Use Do to perform an action
Use Assert to test for success/failure

[Specification]
public void StoreWithOneProduct()
{
    const string productId = "prod-1";

    var store = default(Store);

    "Given a new store".Context(() => store = new Store());

    "with one product".Do(() => store.AddProduct(productId));

    "The store has that product".Assert(() => Assert.True(store.HasProduct(productId)));
}

Because SubSpec is built on top of XUnit any runner that is able to run XUnit tests can run these specifications. I’ve used the freely available XUnit Runner for VS2012 and got this results:

As you can see the strings used are shown as the test name making it easy to understand what is being tested.

Wait there’s more

One problem I always have is tests that test more than one assertion. The problem is that if one assertion fail we cannot know what is the status with the other assertions being tested. SubSpec has a cool solution – run each assertion as a different test:

[Specification]
public void StoreWithOneProduct()
{
    const string productId = "prod-1";

    var store = default(Store);

    "Given a new store".Context(() => store = new Store());

    "with one product".Do(() => store.AddProduct(productId));

    // Usually this line would cause the line after it to fail
    "Customer can purchase that product".Assert(
        () => Assert.True(store.BuyProduct(productId)));

    "The store has that product".Assert(() => Assert.True(store.HasProduct(productId)));
}

SubSpec has actually run two separate tests one for each assertion. But in case you want a proof – let’s write a test with a failing assertion:

[Specification]
public void StoreWithOneProduct()
{
    const string productId = "prod-1";

    var store = default(Store);

    "Given a new store".Context(() => store = new Store());

    "with one product and product is purchased".Do(() => 
        {
            store.AddProduct(productId);
            store.BuyProduct(productId);
        });

    // this is wrong - stop copy/pasting your tests :)
    "Customer can purchase that product".Assert(
        () => Assert.True(store.BuyProduct(productId)));

    "The store does not have that product".Assert(() => Assert.False(store.HasProduct(productId)));
}

And the result of this test run is:

The 2nd assertion passed since it was run independently from the 1st failing assertion.

Running all of the assertions in one test

What if you do need to run all of the assertions in one test? Simple, use Observe keyword that cause all of the assertions created within it to run in the same context.

[Specification]
public void PushSpecification()
{
    var stack = default(Stack);
    "Given a new stack".Context(() => stack = new Stack());

    string element = "first element";
    "with an element pushed onto it".Do(() => stack.Push(element));

    "the stack is not empty".Observe(() => Assert.False(stack.IsEmpty));
    "the stacks Top is the pushed element".Observe(() => Assert.Equals(element, stack.Top));
}

And yes – you can mix Assert and Observe in the same test – and Godspeed on that.

Is that All

Yes!

This is all you need to know in order to use SubSpec, there’s nothing more. It’s simple compact and works. Johannes Rudolph - the creator of SubSpec has taken pains not to add anything else to his frameworks keeping it simple and very small.
But so far I failed to find any limitation that prevents me from using SubSpec and XUnit to quickly add behaviors to my tests.

Happy coding…

Let’s do TDD–take #2

noreply@blogger.com (Dror Helper) — Thu, 18 Oct 2012 15:29:00 +0000

I’ve been preaching about the benefits of Test Driven Development (TDD) for a long time and for the last two years I’ve been trying to introduce the idea to my team with limited success – some of my co-workers embraced TDD while other "just didn’t get it”.
At first I become frustrated and I’ve tried explaining more and more about it without any real success. When I asked several of my teammates why they fail to even try writing tests before code the answer usually was – “I would but I don’t have enough time for it right now” or “it’s a good idea but it won’t work with this feature”.
One day it hit me – why not get the team to do TDD in a natural environment where they can try it without fear of missing a deadline or writing bad code. And so I gathered the team together in one room for an hour and a half of “TDD training”.
For the exercise I’ve chosen a problem that is simple to solve in small iterative steps (TDD) but very hard to design up front.
The exercise I've used was a roman numeral to decimal convertor. it is a well known problem that luckily for me none of my team had the pleasure of solving in the past.
The slides from this session are available here.
After a short introduction of the problem and a few slides on the subject of TDD I got the team to pair up and try and solve that problem.

It was a fun exercise and some of my co-workers got to try test first for the first time.
I loved the fact The pair that finished first really embraced the methodology. The cool thing is that one member of that pair refused to try TDD for the last year.
We had so much fun that we’ve decided as a team to have this kind of meeting every three weeks.

Happy coding…

DevReach 2012 session

noreply@blogger.com (Dror Helper) — Mon, 08 Oct 2012 19:46:00 +0000

Last week I had the pleasure being one of the speakers at DevReach. I like to thank everybody who attended my talk - “Creating change from within”. I had a full room (the smaller theater) and got good feedback (and questions) from the attendees.

It was a fun, well organized convention and I met some very interesting people – I hope I’ll get a chance to return next year.

I’m going to DevReach

noreply@blogger.com (Dror Helper) — Wed, 19 Sep 2012 17:24:00 +0000

I’m so excited - I’ll be going to DevReach 2012 – as a speaker!

One of my sessions have been selected for DevReach. On the 4th of October at exactly 13:45 I’ll be speaking about how to facilitate change in your dev team.

So if you’re coming to DevReach don’t forget to come by and say hello.

Fluent interfaces in C# – method chaining

noreply@blogger.com (Dror Helper) — Mon, 17 Sep 2012 19:44:00 +0000

For those of you who just tuned in, this is a third post on the subject of fluent interfaces using C#. In case you haven’t read them before – here are my previous posts on the subject:

Introduction
Extension Methods

Right, now that we’re familiar with fluent interfaces it’s time to move to “Method Chaining”.
Method chaining is the most recognized “fluent interface technique”. In fact it’s so popular that some believe it to be the only way to write a fluent API.
The idea behind method chaining is both simple and elegant – each method call returns an object that can be used to call another method that returns an object an so on.

Returning “this”

I guess that an example is in order – unless you’ve started writing .NET code yesterday you should be familiar with the StringBuilder class:

In situations where you need to perform repeated modifications to a string, the overhead associated with creating a new String object can be costly. The System.Text.StringBuilder class can be used when you want to modify a string without creating a new object. For example, using the StringBuilder class can boost performance when concatenating many strings together in a loop.
[From MSDN]

Using the StringBuilder class is simple:

var sb = new StringBuilder();
sb.Append("This is a simple list");
sb.AppendLine();
sb.Append("1. First item: ");
sb.Append(items[0]);
sb.AppendLine();
sb.Append("2. Second item: ");
sb.Append(items[1]);

The code above can also be written like this:

var sb = new StringBuilder()
    .Append("This is a simple list")
    .AppendLine()
    .Append("1. First item: ").Append(items[0])
    .AppendLine()
    .Append("2. Second item: ").Append(items[1]);

It’s up to you to decide which is more readable (#2) the fact is that writing the 2nd example is takes less time (try it), just keep using “.” after each method call.
The method chaining “trick” is in the return value of the method. In this case each method call above returns this at the end:

[SecuritySafeCritical]
public unsafe StringBuilder Append(string value)
{
    if (value != null)
    {
        // Here be code!
    }

    return this;
}

This means that we can invoke more methods on the same class one after the other.
Returning the same type on each method call means that the API is “stateless” – meaning that I can always choose the same methods regardless of the last method invoked.

Conclusion

In this post simple method chaining was introduced using return value of this in order to enable the user of the API to call the same class methods in one chain.
Keep in mind that this is only one technique - there are other ways to create fluent API that uses method chaining and I promise to write more about it in another post.

Happy coding…

Driving in my (electric) car

noreply@blogger.com (Dror Helper) — Mon, 03 Sep 2012 20:04:00 +0000

If you do not know already (why should you?) I ‘m working at Better Place.

My company’s mission is to replace old fashioned, gas fueled cars with electric cars. And we do that by providing the infrastructure that (will) enable drivers to drive their (electric) car wherever they want to go to.

A few months ago I’ve decided to make the move and replace my leased car with an electric one – and last Thursday I got my very own electric car.

SO what do I do at Better Place you ask? in a nutshell my team is responsible for the software in the battery switch stations.

Which I had first hand experience with in the last weekend.

So far it has been a fun ride – and I hope it would continue for a long time.

In the meantime – Happy coding…

Fluent Interfaces in C# – Extension Methods

noreply@blogger.com (Dror Helper) — Mon, 16 Jul 2012 15:25:00 +0000

FOr those of you who haven't read the previous post. This post is the 2nd of many where I explain how to use C# and a bag of tricks to create fluent interfaces – easily.

In the previous post I’ve talked about what fluent interfaces is all about and gave a brief introduction to the subject – in this post we’ll actually get to see some code.

The introduction you might not need

Extension methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type. For client code written in C# and Visual Basic, there is no apparent difference between calling an extension method and the methods that are actually defined in a type.

from C# Programming Guide

First introduced in .NET 3 – extension methods have been widely used to “add” methods to existing class without changing the actual class implementation. Using extension methods is as simple as creating a static method – in fact that’s all it takes.

Using extension methods to create an API

The quick and simple way to create “poor man’s” fluent API is to use Extension methods.

All we need is to create a few static methods and we can transform the following code:

// Instead of using this:       
DateTime.Now.AddDays(14);       
      
// Using extension method we can write:       
DateTime.Now.AddWeeks(2);       
      
// Or even this:       
14.DaysFromNow();

The actual implementation is quite simple – but here it is just in case:

public static DateTime AddWeeks(this DateTime baseTime, int weeks)       
{       
    return baseTime.AddDays(7 * weeks);       
}       
      
public static DateTime DaysFromNow(this int days)       
{       
    return DateTime.Now.AddDays(days);       
}

Thus by using simple method call we managed to transform “14” to “two weeks” – not much but it’s a good place to start.

When to use

Extension methods are best used when the API we’re trying to add is on top some 3rd party component or internal class we do not wish to use.

This method is very effective when using along with “method chaining” where using extension method is a good starting point for the whole API – but more on that in posts to come.

In the meantime keep in mind that one of the best fluent API out there (in my humble opinion) uses extension method extensively:

public static IEnumerable<TSource> Where<TSource>         
                               (this IEnumerable<TSource> source,         
                                Func<TSource, bool> predicate)
       
public static IEnumerable<TResult> Select<TSource, TResult>         
                                (this IEnumerable<TSource> source,         
                                 Func<TSource, TResult> selector)

Cons and pitfalls

There are some problems in “adding methods” to existing class – especially if this class is part of the CLR. In the example above I’ve used extension method on integer to create a new DateTime which has nothing to do with the previous type. I’ve added as method to every single integer in my system. Although I could filter the the use of the new method using namespace it’s still a lot of noise.

Conclusion

This is it – the first tool in your fluent interface belt. Experiment with it and use it wisely. And as always:

Happy Coding…

Fluent Interfaces in C#–Introduction

noreply@blogger.com (Dror Helper) — Mon, 02 Jul 2012 18:57:00 +0000

Not many developers are familiar with the concept of DSLs (Domain Specific Languages) even fewer use them in their day job. It seems that creating a new language is a hard job that should only be left for professors in the academia or certain employees that work in Microsoft, Sun or some other compiler vendor.

But not all languages are created equal in the world of DSLs, there is a branch of languages called “Internal DSLs” – that any developer worth his salt can leverage to create better, more readable code.

Internal DSLs and fluent interfaces

The basic idea of a domain specific language (DSL) is a computer language that's targeted to a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem. Domain specific languages have been talked about, and used for almost as long as computing has been done.

Martin Fowler – DomainSpecificLanguage

And so internal DSL (a.k.a “Embedded DSL) is a domain specific language created using an existing (host) language.

Within the group of internal DSLs there is sub group known as “fluent interfaces” – basically using the host language to create code that can be easily read – and look (after a fashion) just like plain English.

The term “Fluent Interfaces” was coined by Eric Evens and Martin Fowler and it refers to an implementation of object oriented API on top of existing functionality in order to provider more readable code.

Why should you care?

There are many benefits of using fluent interfaces – you can create a easy to use and understand API that does not require any additional libraries to implement.

That API provides directions on how the code should be used and can help your users use your software or you can use it internally in order to make a complicated process easy to code by your teammates.

There is one catch – creating a good API is always difficult and creating fluent interface requires understanding of certain tricks in the language that can be leveraged to create the desired code.

C# just like any other object oriented language has the capability to create fluent API in fact certain feature of C# makes it extremely easy to create such API.

What's next

In the upcoming posts I’m going to show a few tricks that I’ve used in the past to create fluent interfaces all of which you probably already know.

So until next time – happy coding…

Software news – May 2012

noreply@blogger.com (Dror Helper) — Wed, 30 May 2012 19:17:00 +0000

Again it’s that time! I have some cool new/updates software I want to tell you about. This time I got three products for the .NET developer that were just released.

nDepend V4

A new nDepend version was just released with a few features but I just got to play around with two of them:

The first new feature is CQLinq is! In the past I’ve used CQL (Code Query language) to create nDepend rules. from now on I’m going to use the new Linqish derivative that enable me to do much much more.

Other new big feature is the nDepend API along with power tools – with full documentation and code examples on how you can use the new API to make your code better.

GitHub for windows

I’ve been planning to host my next pet project on GitHub for some time. I’ve found tutorials and screencasts and there goes these guys at GitHub and create a working, easy-to-use windows client – github:windows.

This new tool bring one install to rule the all, that puts shell as well a well crafted, easy to use and visually compelling windows (WPF) client.

You still to know what you’re doing but using Git has just got a lot easier for windows users.

SharpDevelop 4.2

The lightweight, free (open sourced) .NET IDE has just celebrated another release. In this release adds .NET 4.5 targeting support, ASP.MVC 3 support, MSpec integration, and more T4 template support (which I wish for in Visual Studio). There's more to this release just head for the official release notes page for more details.

If you’re looking for a good Visual Studio alternative – for development at home (or maybe small business) have a look – you might like it.

Happy coding…

Are you better at math or code?

noreply@blogger.com (Dror Helper) — Tue, 01 May 2012 06:25:00 +0000

“Choose a number from 1 to 10” – they usually choose 5, I’m not sure why.

This how an interview question I’ve used to ask begins…

The question

Suppose you’re writing a client that receive a message with a number N (usually 5). Next you’ll receive N messages each contains a different number from 1 to N

1 2 3 4 5

Simple. At this point the interviewee start looking for a catch, but being a kind soul that I am I reassure him that it’s yet to come…
Now to make things interesting the ordering of the messages (i.e. numbers) is not defined – in face you can receive the numbers in any order.

For example I could receive 2 3 4 1 5 or 3 5 1 3 4

Still here?
And finally we know for certain that one of the numbers will not be sent while another will be sent twice

For example: 2 3 1 5 1

That’s it. So now design an algorithm that will return two pieces of data – which number was not sent and which was sent twice. in the last example the output should be 4 and 1.
That a few minutes to think on how to solve this problem.

The reason I used to ask this question is that you can learn quite a lot by the way that this question is answered. The trick is that it’s actually two separate questions:

Which number appeared twice
Which number was not sent

As software developers we’re expected to have some math skills and (hopefully) can code.
I’ve noticed that developers with strong math skill usually answer one first while developers that feel more comfortable with code choose to answer the other. Most answered both but it’s the way that counts.
Note: Just to make things clear – I believe that good developers are good in both fields but usually are better at one than the other.
Are you ready for the answer(s)? here it is:

Which number appeared twice

To find out which number appears twice you’ll need an array of size N (which we know) of Boolean or integers and each time a number arrive just go to that number’s index (or index – 1 because the array starts with ‘0’) if it’s marked false (or 0) just change that cell value to true (or 1) but if it was already previously changed you know that this is the number that appears twice – simple.
I found the developers that are stronger in code find this solution faster then the other.

Which number was not sent

Most math centric developers quickly look at the input and see that it’s an arithmetic progression – a sequence of consecutive numbers and knowing that they also know that the sum of these numbers can easily be calculated:

The sum on our example (again 1 to 5) is (1 + 5) X 5 / 2 = 15.
Now we have a sum without the number that appeared twice – no problem. In math there is a trick of assuming that we’ve solved the first question (which number appeared twice) all we need to do is add it to the sum so in our example 1 is added to result in 16.
After that all you need to do is sum the numbers as they arrive and in the end subtract the new sum from the expected and get the number that was not sent:
16 – (2 + 3 + 1 + 5 + 1) = 16 – 12 = 4.

Conclusion

I don’t think that being better in one over the other makes a better programmer the only reason I’ve asked this question is to find if the candidate had basic skills at both and which of these he’s better – a way to understand who am I talking to.
I hope that you took the time to solve the question before reading the solution so now you know which field you feel more comfortable in.

Happy coding…

Creating robust tests with Isolator V7

noreply@blogger.com (Dror Helper) — Tue, 10 Apr 2012 19:18:00 +0000

The problem with unit tests is that they keep on breaking…

Obviously that’s not entirely correct, nevertheless I had the pleasure of hearing the sentence above numerous times. It’s true – unit tests do tend to fail and we prefer that they fail only when a regression occurs – when something that used to work stopped working, because that’s the reason they’re there in the first place.
The problem is that there are several instances when a test stops compiling due to requirement change or refactoring. consider the following test code:

[Test]
public void Add_AddTowNumbersInCalculator_ReturnResult()
{
    var fakeDataAccess = Isolate.Fake.Instance<dataAccess>();
    Isolate.WhenCalled(() => fakeDataAccess.Save(null)).WillReturn(true);

    var customer = new Customer(fakeDataAccess);

    //...

    var result = customer.Save();

    Assert.That(result, Is.True);
}

Simple. Now what happens when we need to change the Customer c’tor? – let’s say that it was decided that every customer should have a valid address the developer implement that requirement – like this:

[Test]
public void Add_AddTowNumbersInCalculator_ReturnResult()
{
    var fakeDataAccess = Isolate.Fake.Instance<dataAccess>();
    var fakeAddress = Isolate.Fake.Instance<Address>();
    Isolate.WhenCalled(() => fakeDataAccess .Save(null)).WillReturn(true);

    var customer = new Customer(fakeAddress, dataAccess);

    //...

    var result = customer.Save();

    Assert.That(result, Is.True);
}

What if I already wrote a few dozen tests – what can I do?

Create overloaded c’tor one with parameter and one parameterless
Add a default value to the c’tor (.NET 4.0)
Write all of the tests again – from scratch
Delete your tests and never attempt unit testing your code ever again
Create a factory method to instantiate Customer at your tests
Quit your job and move to another country

All of the above are valid options (ok, some of these are valid options) they would work great for some of the scenarios. unfortunately most of the time usually you end up re-writing a lot of code each time such a change happen. Adding parameters that you usually do not care about and so you fake them or pass some default value over and over again.
In fact on my team this problem (needing to fix a lot of tests each time the c’tor signature change) was so severe that one of the developers took it upon himself to create a class that creates object just for the test with all of the parameters faked.
Luckily there is another way: the new Isolator V7 that was released a few weeks ago and one new feature got me exited (no not the auto-test-runner) – it’s The new API calls: Isolate.Fake.Dependencies and Isolate.GetFake.
Using the new API I’ve fixed the test to work like this:

[Test]
public void Add_AddTowNumbersInCalculator_ReturnResult()
{
    var customer = Isolate.Fake.Dependencies<Customer>();

    var fakeDataAccess = Isolate.GetFake<DataAccess>(customer);
    Isolate.WhenCalled(() => fakeDataAccess.Save(null)).WillReturn(true);
    //...

    var result = customer.Save();

    Assert.That(result, Is.True);
}

I just tell Isolator to fake all dependencies and “grab” the only one that interest me at this test and change it’s behavior – simple.
And now my test won’t break due to c’tor changes.

Happy coding…

AOP sessions on IDNDUG

noreply@blogger.com (Dror Helper) — Wed, 21 Mar 2012 20:20:00 +0000

I’ve just come back from my dual session on AOP on the local user group. The first part was introduction to AOP – what is it and why should you care.
I’ve also reviewed several ways to implement AOP in your code from functional programming to full AOP frameworks.

Introduction to aop

View more presentations from Dror Helper.

The source code for this presentation can be downloaded from here.
The 2nd session was all about PostSharp and how to use it to do cool stuff from simple logging to lazy loading and adding attributes and interfaces at compile time.
I won’t post the slides for the second session most of it was done in Visual Studio. All of the code I’ve shown can be downloaded here.
The examples are also available here.
I had a great audience – they participated and asked a lot of questions most of which I managed to answer.

All in all a good day…

NUnit’s new Action Attributes is AOP to your unit tests

noreply@blogger.com (Dror Helper) — Wed, 07 Mar 2012 19:16:00 +0000

With the new NUnit release (v2.6) introduce a new feature called Action Attributes which means that now NUnit has rolled out it’s own mini-AOP capabilities.

In the past SetUp and TearDown where used to perform actions before and/or after a test run, they worked well enough but were limited to running certain operation only on the tests on that test class – on all thee tests. Confronted with the need to perform the same operation for multiple test classes the test writer (you) needed to resort to inheritance which is not bad solution as long as you do not need to support multiple "pre/post behaviors on some of the tests.

And there was always the solution of writing the same code over and over in all of the tests either as duplicating the code or putting it inside a method and calling it from all the tests. Sounds familiar? To me it sounds just like a case of a simple cross-cutting concern.

How it works

All you have to to is implement the following interface:

public interface ITestAction
{
    void BeforeTest(TestDetails details);

    void AfterTest(TestDetails details);

    ActionTargets Targets { get; }
}

and that’s it! For more details – head to NUnit’s site for full description.

Now adding Aspects is as simple as creating a class and then putting the attribute on a method, class or even assembly:

[TestFixture, ResetServiceLocator]
public class MyTests
{
    [Test, CreateTestDatabase]
    public void Test1() { /* ... */ }

    [Test, CreateTestDatabase, AsAdministratorPrincipal]
    public void Test2() { /* ... */ }

    [Test, CreateTestDatabase, AsNamedPrincipal("charlie.poole")]
    public void Test3() { /* ... */ }

    [Test, AsGuestPrincipal]
    public void Test4() { /* ... */ }
}

Any issues?

The only downside is the being a new feature it’s only supported by NUnit’s GUI and console runners. This means that if you’re using a 3rd party runner such as TesDriven.NET, R# or CodeRush you’ll have to wait until support is added in some future release.

Conclusion

In the past other testing frameworks such as MBUnit (and even MSTest) had similar features – but never this simple.

There you have it – simple unit testing AOP curtsy of NUnit. Now that I have it I don’t understand how I never felt that this functionality was missing. The new Action Attributes really shine in integration tests. Making database setup, running under specific permissions or just making sure a server is up before running the tests.

Happy Coding…

Software news – February 2012

noreply@blogger.com (Dror Helper) — Wed, 29 Feb 2012 20:30:00 +0000

It’s been a while since last I’ve written about new releases and features in software I like so I’ve decided to shine a light on three software development tools I love, two exiting beta releases and one hidden feature brought into the light:

SharpDevelop 4.2 Beta

The open source, light free .NET IDE has just announced another beta release. I’ve been following #Develop since it was created in the midst of .NET 1 and it just keeps on getting better. This release has a few cool features such as ASP.NET MVC 3 support and MSpec support – with an integrated test runner.

The good people of #Develop have added an additional static analysis tool - the dependency metrix.

It always amaze me on how this tool finds new way to innovate and I hope that the Visual Studio team look at this tool from time to time to see what is still missing from Visual Studio.

PostSharp Toolkits

If you don’t know what PostSharp or AOP is – it’s not too late to learn. In a nutshell PostSharp utilize attributes to add cross cutting concerns into existing .NET code. But for those of you that don’t like to see additional attributes on their code there is a new tool on the block. Using NuGet you can add logging to every function on the code with a click of a button. And the great thing is that it’s open source, I plan to dig into the code and find out if I can use the power of the PostSharp SDK…

If you want to know more about it - Igal has written all about it on the SharpCrafters blog.

Isolator 7 Beta

Disclaimer – I used to work at Typemock, regardless I believe that the next Isolator release is going to make some waves. In the next version (V7) Typemock Isolator becomes more than a “mocking tool”. The new Autorunner feature that runs all of the unit tests in the background while checking code coverage is just what I need in my team with the 3000+ tests we have. But that’s not all – Typemock has taken the idea of auto-mocking containers to the next level with the ability to create a fake instance and change the behavior of its dependencies after creation – it’s quite a lot to explain here, I’ll have to write a post just for this feature.

So if it’s sounds interesting – check out this webcast or better yet head to the beta sign-up page and see for yourself.

Why you need to make your tests fail

noreply@blogger.com (Dror Helper) — Wed, 15 Feb 2012 20:50:00 +0000

Test Driven Development (TDD) have many benefits. For start it’s a design methodology that help avoiding “Analysis paralysis” and make sure that you only have the needed code to solve a problem.
Yesterday I found another benefit of writing the tests before the code – you get to see them fail!
A while back I wrote about another shortcoming of MSTest – how it does not have any built in facility to test against expected exception message.

Unknown to me at the time there was a bug hidden in the code I’ve published – see if you can spot it:

public static class MyAssert
{
    public static void BadThrows;<T>(Action action) where T : Exception
    {
        try
        {
            action();

            Assert.Fail("Exception of type {0} should be thrown.", typeof(T));
        }
        catch (T exception)
        {
     // All is well!
        }
    }
}

BTW this example was simplified for your viewing pleasure - I want to make a point here, not stick to the facts. have you found the bug yet?

Consider the following test:

[TestMethod]
public void ThisTestWouldNeverFail()
{
    MyAssert.BadThrows<exception>(() => Dummy.SomeMethod());
}

Have you guessed it? (hint: its in the test name)

That's right! this test would never have failed. If we take a closer look at BadThrows we’ll see the problem.

MSTest just like any other .NET unit testing framework throws an exception when assertions fails. In this case because we’re expecting an exception of type Exception any other exception thrown including the AssertFailedException would be caught – causing the test to pass.

That’s right – because the user expects an exception of type”Exception” to be thrown plus a minor bug the test is completely useless – if you want to see the working code just head to this post.

I did not find this bug mainly because I don’t like to throw and assert for Exception seems like a bad practice and in retrospective I should have avoided my co-workers from doing so by throwing exception of my own in case they try to do it.

The guy that did find this bug found it because he wrote a test and wanted to see it fail. That’s right it wasn’t enough for him to know that his code made the test pass – he had to make sure that it failed first – some people…
A quick search in our code found multiple tests that did exactly that which means two things:

These test were not written using TDD
The authors did not even bother to see the tests fail

After fixing the bug we found one test that started failing – which means that not only was the test wrong – so was the code it was testing.

I’ve talked to the team, explained why throwing “Exception” is not a best practice and why tests need to be “tested” by seeing them fail and we’ve fixed the tests and the code.

I think I learnt quite a lot from this experience, I know now who does TDD and who doesn’t and I found a new problem that occurs when developers write their tests after the code.

Happy coding…