RSS
Facebook
Twitter

Monday, December 15, 2014

New Speaking engagement - DevWeek 2015

Now that I’m back from NDC London I have a chance to plan my upcoming speaking engagements – and it’s going to be a few busy months.
I’ve already blogged about my plans  for the next few months but since then I found out that I’ll be coming back to London (always a pleasure) in March for DevWeek.
image
The agenda looks amazing, good speakers and good talks and I’m happy to have three sessions – one for each day:

Navigating the TDD alphabet soup

TDD, BDD, ATDD are all methodologies that enable incremental design that is suitable for Agile environments. It seems that every day a new xDD methodology is born with the promise to be better than what came before. Should you use behavior-driven tests or plain old unit tests? Which methodology is better? And how exactly would it benefit the development life cycle?
In this session, we’ll sort out the various methodologies – explaining where they came from, the tools they use, and discussing how and when to use each one. Here we will once and for all answer the question as to whether or not there’s one “DD” to rule them all.

Battle of the .NET mocking frameworks

Writing unit tests is hard, isn’t it? You need an entire set of tools just to start. One of the crucial decisions when building this set is picking up a mocking framework. But BEWARE! What you choose has the ability to make you or break you! In this session, This talk will cover the capabilities and functionality of the leading frameworks, showing the good and the bad of the different options (both free and commercial), and making them battle to the death!

Unit testing patterns for concurrent code

Getting started with unit testing is not hard, the only problem is that most programs are more than a simple calculator with two parameters and a return value that is easy to verify. Writing unit tests for multi-threaded code is harder still. In this session, I will demonstrate useful patterns that he has discovered over the years, and that have helped him to test multi-threaded and asynchronous code and enabled the creation of deterministic, simple and robust unit tests. He will also point out the pitfalls to avoid.

Hope to see you there!

Sunday, November 23, 2014

Unit testing concurrent code using custom TaskScheduler

Today I had a need to test an action that runs inside a Task:
public class ClassToTest
{
    private readonly IMessageBus _messageBus;
    private CancellationTokenSource _cancellationTokenSource;
    public event EventHandler OnNewMessage;

    public ClassToTest(IMessageBus messageBus)
    {
        _messageBus = messageBus;
    }

    public void Start()
    {
        _cancellationTokenSource = new CancellationTokenSource();
        Task.Run(() =>
        {
            var message = _messageBus.GetNextMessage();

            // Do work

            if (OnNewMessage != null)
            {
                OnNewMessage(this, EventArgs.Empty);
            }

        }, _cancellationTokenSource.Token);
    }

    public void Stop()
    {
        if (_cancellationTokenSource != null)
        {
            _cancellationTokenSource.Cancel();
            _cancellationTokenSource = null;
        }
    }
}
When faced with similar a code a developer has a “tiny” problem – how to force the code inside Task.Run to execute before the end of the test is reached.
And so we can write the following test that would fail - most of the times:
[TestMethod]
public void BadTest()
{
    var fakeMessageBus = A.Fake<IMessageBus>();
    var wasCalled = false;

    var cut = new ClassToTest(fakeMessageBus);
    cut.OnNewMessage += (sender, args) => wasCalled = true;

    cut.Start();

    Assert.IsTrue(wasCalled);
}

Why you should not use Thread.Sleep

The trivial fix would be to use Thread.Sleep (or similar Task.Delay) to make sure that the action would run before we reach the end of the test. Unfortunately adding this sleep will only cause the test would pass most of the times.
[TestMethod]
public void WorseTest()
{
    var fakeMessageBus = A.Fake&lt;IMessageBus&gt;();
    var wasCalled = false;

    var cut = new ClassToTest(fakeMessageBus);
    cut.OnNewMessage += (sender, args) =&gt; wasCalled = true;

    cut.Start();
    Thread.Sleep(1000);

    Assert.IsTrue(wasCalled);
}
The problem is that by adding a sleep we managed to achieve an inconsistent test while also making sure that the test would run a staggering 1 second – if that doesn’t sound like a lot think how much time 60 of such tests would run, what about 1000 tests each taking a single second?
In any case creating a test that could fail or pass inconsistently is a huge problem – it only takes a few such failures to convince your team to stop paying attention to that test – because it’s the test that always fail and soon enough they’ll stop paying attention to the continuous integration results and all of your tests would become useless (at least for alerting the team when a bug is introduced).

Creating a custom TaskScheduler

Looking for a solution I found a good post by Kjetil Klaussen where he suggests creating a new TaskScheduler that would cause the task to run in the same thread as the test thus causing the test to be predictable and simple:
public class CurrentThreadTaskScheduler : TaskScheduler
{
    protected override void QueueTask(Task task)
    {
        TryExecuteTask(task);
    }

    protected override bool TryExecuteTaskInline(
       Task task,
       bool taskWasPreviouslyQueued)
    {
        return TryExecuteTask(task);
    }

    protected override IEnumerable<Task> GetScheduledTasks()
    {
        return Enumerable.Empty<Task>();
    }

    public override int MaximumConcurrencyLevel { get { return 1; } }
}
Now we need to pass that scheduler to the executing task either by using a wrapper object or dependency injection.

Changing the current TaskScheduler

The problem is that you need to change your production code which is not always simple just like in my case where the action I needed to run was 5 calls deep and I didn’t want to pass the new TaskScheduler to each class on the calling stack.
I’ve started to look of a way to replace the current task scheduler.  Tamir D had a better idea - run the entire test inside a Task with CurrentThreadTaskScheduler.
Following his advice I’ve changed the Start method:
public void Start()
{
    _cancellationTokenSource = new CancellationTokenSource();
    Task.Factory.StartNew(() =>
    {
        var message = _messageBus.GetNextMessage();

        // Do work

        if (OnNewMessage != null)
        {
            OnNewMessage(this, EventArgs.Empty);
        }

    }, _cancellationTokenSource.Token, 
    TaskCreationOptions.None, 
    TaskScheduler.Current);
}
And now I could write the following test that would pass every single time.
[TestMethod]
public void GoodTest()
{
    var fakeMessageBus = A.Fake<IMessageBus>();
    var wasCalled = false;

    Task.Factory.StartNew(() =>
    {
        var cut = new ClassToTest(fakeMessageBus);
        cut.OnNewMessage += (sender, args) => wasCalled = true;

        cut.Start();
    }, CancellationToken.None, 
    TaskCreationOptions.None, 
    new CurrentThreadTaskScheduler());

    Assert.IsTrue(wasCalled);
}
Another benefit is that I could also test for negative conditions (something didn’t happen) since now all of the code runs synchronously.

Want to learn more?

There are many other ways to unit test concurrent code - if you’re interested in learning more ways to unit test concurrent code – I’ll be speaking about this topic at upcoming NDC London next week.

Until then - Happy coding…

Tuesday, November 18, 2014

Agile practitioners conference 5Whys challenge

If you’ve been following my on Twitter (or read this blog) you might know I’m part of the organizing committee of the upcoming Agile Practitioners conference.

banner11
In the last couple of weeks we’ve asked each speaker to answer five simple questions (a.k.a 5Whys) and got some interesting results:
Reading these made we want to write my own answers (technically I had to since I’ll be speaking at the conference as well) and as a reader of this blog you get to read them before everybody else.

Why should people come to the conference?

It is a great opportunity to meet other professionals who are passionate about being agile and want to learn more. In the past I had interesting conversations with conference attendees and learnt quite a lot.

Why should people come to my session?

To learn about TDD :)
If you want to add another great design methodology to your tool belt - this is the session you need to hear.
It doesn't matter if you tried TDD in the past or just beginning with unit testing.

Why did I choose the topic?

There have been quite a lot of misunderstanding in this field and although it seems as if TDD exist since the beginning of time it is still misunderstood and misused.
I hate to see software developers avoid this practice due to bad experience and lack of understanding of how it works and so I've decided to create a session that shows TDD with a "real" application - not just a trivial example.

Why I think you should go to “Agile from the executive floor – defining agility in business termsby Yuval Yeret?

I've been a software developer for a long time. Having to explain to "top brass" how a proposed change would benefit the organization become part of my job and so I want to hear Yuval's experience and incites on the topic.

Why did the chicken cross the road?

There is no chicken...
Chickens at the Kings Arms in Wing, Rutl by Jez B, on Flickr
Creative Commons Creative Commons Attribution-Noncommercial-No Derivative Works 2.0 Generic License   by  Jez B 

Sunday, October 19, 2014

4 programming books available online - for free

Software development books don’t come cheap and it’s fine. The author has spent countless hours and sleepless nights transferring his/her knowledge and should be compensated for it.
But some authors have decided to provide an online version of their book and in some cases even a free e-book you can download.
I found the book in the list below extremely useful and since I read them for free (legally free) I wanted to give something back in the form of a recommendation – so that both the author and and you might benefit from these good books.

 

Threading in C#

This is the only entry which is not a standalone book - It’s actually two chapters from C# in 4.0/5.0 in a nutshell book.
I’ve used (and still using) this book extensively both for learning new threading topics and as a reference. I found it to be easy to read and understand as well as extensive without being overwhelming.
It’s a must book for C# developers who need to write multi-threaded/task based/async code – which is about every C# developer out there.
Availability: Online, PDF

Introduction to Rx

IntroToRx_Cover
Although not the newest book on the subject this book is still relevant. This book guide you step by step on the path of using Reactive Extensions (Rx).
For only a few dollars (or less) you can purchase a kindle edition of this book.
Availability: Online

Dive into Python

cover-small
I’ve read this book when I’ve decided to learn IronPython a few years ago.
This book teaches by example - each chapter begins with a code example that shows an example of the chapter’s topic that is explained throughout  the chapter.
Availability: Online, PDF, Word and more.

Pro Git

pro-git@2x
If you never used a distributed source control before (you are using source control – right?) this is a good book to learn from.
It takes you step by step, not only explaining the various Git commands but also the concepts and overall picture of using a distributed system.
After reading a few chapters not only you’ll be able to set up Git and use it successfully but also gain a better understanding on why Git works this way and how to utilize it to benefit your project.
Availability: Online

That’s it for now - now go do some reading…

Thursday, October 16, 2014

Upcoming conferences

As 2014 ends and the new year begins I have a few speaking opportunities planned right around the corner:

 

NDC_london14_logo_boxed

When: 3rd December 2014

I’ve enjoyed speaking at NDC London last year and I’m glad I was given a chance to speak at that great conference again. I’ll be speaking about unit testing concurrent and asynchronous code – the session to end all (read: some) excuses not to unit test.

 

image[15]

When: 28th January 2015

I’ve been a long time speaker at the Agile Practitioners conference and this year I’m also a part of the organizing committee. I have a session planned “Designing with Tests”.

 

speaking

When: 18th-20th February 2015

I’m going to Canada to speak at ConFoo

I have two sessions planned – Who’s afraid of WinDbg?, and Unit testing patterns for concurrent code. This is my first time at ConFoo but I heard good things about this conference and I’m sure it would be fun to attend.

 

What a great way to start 2015 – three great conferences. If you happen to attend one (or more) of these conferences - drop by, say hello and let me know what you think about my talk.

Monday, October 13, 2014

Strongly typed localized strings in universal apps

Back in the old days when the need for localized string arose, I would add a new string and use AppResources to access the correct string in code.
In Windows Phone application (known today as Windows Phone Silverlight 8.0/8.1) I would do something like this:
public void SomeMethod()
{
    var localizedString1 = AppResources.MyFirstSring;
    var localizedString2 = AppResources.AnotherString;
}

In the new universal apps the story is a bit different:
  • Only strings are allowed in the resource files (which are .resw instead of .resx)
  • Using a directory for each supported language (i.e. Strings\en-US\)
  • Access to localized strings is string based
I can live with the first two (I actually prefer it that way) but I have huge problems with Stringly Typed API calls – it’s easy to get it wrong, and even worse a trivial rename can cause problems that would only show during application run.

Luckily a co-worker of mine has put together a T4 template that fixes this problem (thanks Noam):

<#@ template debug="false" hostspecific="true" language="C#" #>
<#@ assembly name="System.Core" #>
<#@ assembly name="System.Xml" #>
<#@ assembly name="System.Xml.Linq" #>
<#@ import namespace="System.Linq" #>
<#@ import namespace="System.Xml.Linq" #>
<#@ import namespace="System.Text" #>
<#@ import namespace="System.Collections.Generic" #>
<#@ output extension=".cs" #>

<# string str = this.Host.ResolvePath("strings\\en-us\\Resources.resw");
    System.Xml.Linq.XElement resXml = System.Xml.Linq.XElement.Load(str); // Read a data file here. "%aaa%/string/en-us/Resources.resw"
   IEnumerable<XElement> appElement = (from dataElements in resXml.Descendants("data") select dataElements); #>

using Windows.ApplicationModel.Resources;

namespace UniversalApp
{
    public class StringsResourceManager
    {
        private static readonly ResourceLoader _resourceLoader = new ResourceLoader();
        public StringsResourceManager()
        {
        }

<# foreach (var element in appElement) { #>  
        public static string <#= element.Attribute("name").Value.Replace(".","_")#>  
        {
            get
            {
                return _resourceLoader.GetString("<#= element.Attribute("name").Value#>");
            }
        } 
<# } #>
    }
}

Using the class created from this template I can get from this:
public void SomeMethod()
{
    var resourceLoader = new ResourceLoader();

    var string1 = resourceLoader.GetString("MyFirstSring");
    var string2 = resourceLoader.GetString("AnotherString");
}

To this:
public void SomeMethod() 
{ 
    var string1 = StringsResourceManager.MyFirstSring; 
    var string2 = StringsResourceManager.AnotherString; 
}


Happy coding…

Monday, September 29, 2014

What I hate about BDD

Disclaimer: this is not a TDD vs. BDD post – now that we’ve got that out of the way let’s discuss the thing I hate most about BDD…

I’ve recently started using BDD (again). My tests are still “unit tests” – they do not call a database nor any other external dependency, and since even when writing unit tests I aim to test functionality (mini-requirements) most of them didn’t change too much.
For the subject of this experiment I’ve chosen BDDfy which was a perfect fit for my needs.
Some BDD frameworks uses two “kinds” of files – text file(s) where the scenarios and stories are written (in plain text) and code file(s) that implement the functionality that correspond to steps in those scenarios.
BDDfy on the other hand uses code file which is also used to generate the specification – so less work for me.
By using BDDfy I can transform the following unit test:
[TestMethod]
public void RejectCall_UserRecieveCallAndRejectIt_SendReport()
{
    var fakeMessageEngine = A.Fake<IMessageEngine>();
    var phone = new Phone(fakeMessageEngine);
    var notificationService = new NotificationService(phone);

    var message = new NewCallMessage("otherUserId");
    fakeMessageEngine.OnMessageArrived += Raise.With(new MessageArrivedEventArgs(message)).Now;

    phone.AnswerCall(Answer.Reject);

    var result = notificationService.GetLastReport();

    Assert.AreEqual(ReportType.CallEnded, result.ReportType);
}

To something like this:

[TestClass]
public class NotificationBddTests
{
    IMessageEngine _fakeMessageEngine;
    Phone _phone;
    NotificationService _notificationService;

    public NotificationBddTests()
    {
        _fakeMessageEngine = A.Fake<IMessageEngine>();
        _phone = new Phone(_fakeMessageEngine);
        _notificationService = new NotificationService(_phone);
    }

    [TestMethod]
    public void RejectCall_UserRecieveCallAndRejectIt_SendReport()
    {
        new NotificationBddTests()
            .Given(s => s.RecievedCallFromUser())
            .When(s => s.CallRejected())
            .Then(s => s.EndCallReportAdded())
            .BDDfy();
    }

    private void RecievedCallFromUser()
    {
        var message = new NewCallMessage("otherUserId");
        _fakeMessageEngine.OnMessageArrived += Raise.With(new MessageArrivedEventArgs(message)).Now;
    }

    private void CallRejected()
    {
        _phone.AnswerCall(Answer.Reject);
    }

    private void EndCallReportAdded()
    {
        var result = _notificationService.GetLastReport();

        Assert.AreEqual(ReportType.CallEnded, result.ReportType);
    }
}

And it’s an improvement – the test is more readable and well organized.

But there’s a hidden “price” for writing this kind of tests – one that can cause brittle tests and stability issues in the near future – can you spot the problem?


It’s all about shared state

I have a confession to make: most BDD code samples on the internet cause me to cringe. They all have the same inherent flaw. It’s all about “how we test the real requirements” and “create living specification” but no one ever talks about the fact that the test above could become a huge maintainability issue!

The problem could be shown easily with the following example:

[TestClass]
public class ShoppingCartTests
{
    private readonly ShoppingCart _cart = new ShoppingCart()

    [TestMethod]
    public void EmptyCartTest()
    {
        new ShoppingCartTests()
            .Given(s => s.ShoppingCartIsEmpty())
            .Then(s => s.TotalPriceEquals(0))
            .BDDfy();
    }

    [TestMethod]
    public void AddItemTest()
    {
        var newProduct = new Product(id: "prd-1", price: 100
        new ShoppingCartTests()
            .Given(s => s.ShoppingCartIsEmpty())
            .When(s => s.AddProductToCart(newProduct))
            .Then(s => s.TotalPriceEquals(newProduct.Price))
            .BDDfy();
    }

    private void ShoppingCartIsEmpty() { }

    private void TotalPriceEquals(int expected)
    {
        Assert.AreEqual(expected, _cart.TotalPrice);
    }

    private void AddProductToCart(Product product)
    {
        _cart.Add(product);
    }
}

Do you see the field that is being used by all of the tests.

By using the same instance in all of the tests we accidently cause the test to pass (or fail) depending on the order in which they were run. Obviously it’s an easy fix (in this case), Unfortunately such a simple issue can become a huge problem, the more tests written the more initialization logic required and before you know it it’s the middle of the night and you’re using trying to figure out how could a test that used to work fails some of the times - for no apparent reason.

This is not a BDD problem – I can easily write (and written) the same code without the aid of a BDD framework. However it does seem as if all BDD framework push you towards this issue.


The Solution

Luckily it’s easy to avoid this issue completely – make sure that tests do not share the same state (I said it was easy).

I’ve created a new class called NotificationTestBuilder (because naming things is the hardest thing in programming) and shoved all of the test’s “state” inside it.

And now I can write the same BDD test using single state per test:

public class NotificationTestBuilder
{
    IMessageEngine _fakeMessageEngine;
    Phone _phone;
    NotificationService _notificationService;

    public NotificationTestBuilder()
    {
        _fakeMessageEngine = A.Fake<IMessageEngine>();
        _phone = new Phone(_fakeMessageEngine);
        _notificationService = new NotificationService(_phone);
    }

    public void RecievedCallFromUser()
    {
        var message = new NewCallMessage("otherUserId");
        _fakeMessageEngine.OnMessageArrived += Raise.With(new MessageArrivedEventArgs(message)).Now;
    }

    public void CallRejected()
    {
        _phone.AnswerCall(Answer.Reject);
    }

    public void EndCallReportAdded()
    {
        var result = _notificationService.GetLastReport();

        Assert.AreEqual(ReportType.CallEnded, result.ReportType);
    }
}

[TestClass]
public class NotificationBddTests
{
    [TestMethod]
    public void RejectCall_UserRecieveCallAndRejectIt_SendReport()
    {
        var builder = new NotificationTestBuilder();
        new NotificationBddTests()
            .Given(s => builder.RecievedCallFromUser())
            .When(s => builder.CallRejected())
            .Then(s => builder.EndCallReportAdded())
            .BDDfy();
    }
}

And if I needed to do some “cleaning” after the test has finished running – I can implement IDisposable and put the whole test inside a using block.

And so by creating the state in each test we make sure that they could not effect each other.


Happy coding…
Related Posts Plugin for WordPress, Blogger...