Enlarge your TDD with NFluent

Full disclosure I am an active contributor to NFluent.

Imagine your first days on a new project that has a decent unit tests base (if not, change this or walk away).

You start coding away a fix or new feature, you extend the test base, you happily commit! Then the factory signals a failed build due to failing tests.

Well, that’s expected actually, unit tests are here as a safety net.

Bu then you realize that the test error message does not help. Neither taking a look at the test code, as the assertion’s syntax does not properly reflect the test intents.
Or maybe the previous developer failed to realize that the expected value comes first in Assert.AreEqual, or the comment has not been updated.

In the end, you have to debug the test to understand what is going wrong.

Image

This hassle fuels the naysayers that claim that unit tests are a cute idea but:

  • do not provided added value to the product
  • are expensive to write
  • are a burden in maintenance

They are basically right. Of course this is a short-sighted vision, but those are actual issues with many code base as of now, with the notable exception of OSS.

This is a serious issue that needs to be addressed.

Part of the problem comes from the fact that unit test tools have not significantly changed in the past decade, a time when the main challenges were being able to implement test runners and build testing infrastructures. Then there was interest in building more efficient test runners with the integration of multiple scenario for a single test, or the generation of variants. But no significant effort regarding the API.

Coming back to my earlier example, we, TDD craftsmen, need an API that allows us to be expressive on the assertion/checks we make. We want the IDE to help us, typically through Intellisense, we want to be able to add our own tests, we want to express conjoined test criteria as a single check and we want to ensure that newcomers (including our proverbial ‘future self’) to understand clearly what the test is about.

nFluent has been designed to answer those requirements as well as some others. It is on OSS assertion library that works on top of all unit test frameworks (nUnit, mbUnit, xUnit, even MSTest). You can start using now on any existing code base or new project. It is available through nFluent and it is guided by the brilliant T.Pierrain (@Tpierrain).

Check it: http://n-fluent.net/

Can you spot the Deadlock 4: the solution!

Can you spot the Deadlock 4: the solution!

As most of you correctly highlighted, the last exercise exhibits a deadlock situation. The main thread here simply creates and starts another thread and waits for its completion, but this expectation is never fulfilled.

class Program
{
  static void Main(string[] args)
  {
    var workerThread = new Thread(Worker);
    workerThread.Start();
    workerThread.Join();
  }
...

When one looks at the worker thread code, you realize that the stopping condition is never going to be met: Thread.CurrentThread.IsAlive just cannot be false! The current thread is alive, otherwise it will be dead, hence not executing code.

...
  static void Worker()
  {
    while (Thread.CurrentThread.IsAlive)
    {
      Console.Write("Blah");
    }
  }
}

Based on a true story, this example shows a very common misconception, that the framework provides facilities to control the life cycle of threads, and for that matter that Join will trigger a graceful stop. Well, sorry to break this to you guys, this is just not happening. It is your responsibility to implement an appropriate mechanism.

Here is a valid implementation using a shared flag:

    public class Solution
    {
        private readonly object synchro = new object();
        private bool run;

        static void Main(string[] args) {
            var workerThread = new Thread(Worker);
            run = true;
            workerThread.Start();
            lock (this.synchro) {
                run = false;
            }
            // wait for the thread to start
            workerThread.Join();
        }

        private void Worker() {
            for (;;) {
                lock (this.synchro) {
                    if (!run) {
                        break;
                    }
                }
                Console.Write("Blah ");
            }
        }
    }

New! Available on GitHub: for the curious, the critics and the laziest, I have but the code on GitHub as a VS 2012 solution.

Simple Binary Encoding, a new ultra-fast marshalling API in C++, Java and .NET

Nice to see a strongly performance oriented serialization library. It is even better when it is a standard implementation. Try this!

Adaptive Consulting Blog

Welcome to the Adaptive blog!

In this first post we will be talking about Simple Binary Encoder, aka SBE.

Martin Thompson – ex CTO at LMAX, now Real Logic – and Todd Montgomery – ex 29WEST CTO, now Informatica – have been working on a reference implementation for Simple Binary Encoding, a new marshalling standard for low/ultra low latency FIX.

My colleagues and I at Adaptive Consulting have been porting their Java and C++ APIs to .NET.

Why?

You are probably wondering “why are those guys reinventing the wheel? serialization is a solved problem..”

In many cases I would say you are right, but when it comes to low latency, and/or high throughput, systems this can become a limiting factor. Some time ago I built an FX price distribution engine for a major financial institution and managed to get reasonable latencies at 5x throughput of normal market conditions: sub-millisecond between reading…

View original post 853 more words

Agile carpaccio

An agile elephant Photo by Kevin Philipson on Unsplash

I had the opportunity to beta test an agile carpaccio workshop.

For those who never have heard about this, the carpaccio approach insists that user stories drive your deliverable, up to a point where you are able to deliver on a per user story basis.
The analogy to carpaccio relates to the fact that one is supposed to work through a user story end to end and deliver it, so potentially forcing you to slice your user story in smaller increments that can be delivered within a single sprint. This is typically done by reducing the scope of use cases (see below for an example).

Here is the minutes of this dojo:

User story: compute a total price with an item unit price, a quantity, a (USA) state to identify tax rate and a discount policy based on total price.

Constraints:

  • 8 minutes iterations
  • perform a working demo to the customer at the end
  • demo time is part of the iteration

Initiation: blank project, environment of your choice.

I was pairing with Thomas Pierrain (@tpierrain), so we chose a console application in C# as our delivery package, TDD as our approach.

The end of iteration will be signalled by a ‘Dong’.

Iteration #1:

  • .Created the appropriate project, paired the MBA with an IPhone, used Nuget to retrieve nUnit and nFluent
  • Added a banner to the app, build it.
  • Started working on the first test.

Dong

Iteration #2:

  • Demoed the app, customer is pleased: we are capable developers!
  • Finished first test, which test tax computation.
  • We hard coded the tax rate to the Utah value, as the customer states that most of his business is done there.
  • In a true red green re-factor approach, we hard coded the expected result.
  • Our console app now outputs a sample results, with unit price quantity and taxes.

Dong

Iteration #3:

  • Demoed the app, customer is happy, he can confirm it matches his expectations.
  • Add message and input capture for price, including an input sanity check.
  • Copy paste the code for quantity.

Dong

Iteration #4:

  • Demoed the app, but it is not working, the computed result is zero. We did demonstrate some progress, but also suffered regression.
    This is due to the absence of unit tests for input
  • After the demo, the culprit is quickly identified: copy-paste-incomplete modify.
  • We start working on support for other states.

Dong

End of the exercise.

We have a working deliverable, and it passes the acceptance test, which was to compute a cost for a Utah based delivery. We were probably at 50% of the target, but with only 4 iterations it was not so bad. Most of other teams had implemented more features, but all of them failed to have an actual deliverable, they were still at the prototype stage.

Conclusions

  • It was immensely fun to do fast paced development.
  • It clearly demonstrated the value of having a workable product as soon as the first iteration as a communication media.
  • It also demonstrated it is doable, whatever your iteration/sprint length.

As a summary, a highly recommended exercise, whatever your expertise level is, as it helps us refocus on what matters to the customer.

Link to Alistair Cockburn original exercise: http://alistair.cockburn.us/Elephant+Carpaccio+exercise

Can you spot the deadlock 4 ?!

Hello everyone,

welcome back to can you spot the deadlock take 4. As a reminder, this a puzzle in a form of multithreaded code. You have to identify the issue that hides in it, usually a deadlock, but not always. Please post your answer in the comments section.

Since it has been a long time since the last episode, let’s start easy!

So what is the problem with this code and how would you fix it?

class Program
{
  static void Main(string[] args)
  {
    var workerThread = new Thread(Worker);
    workerThread.Start();
    workerThread.Join();
  }

  static void Worker()
  {
    while (Thread.CurrentThread.IsAlive)
    {
      Console.Write("Blah ");
    }
  }
}