Nancy Fx - now you can read her too!

I fell in love with Nancy at first sight; so slick, minimalistic, testable and understandable, powerful and extendable when I need it. I later learned those features had a name; the SuperDuperHappyPath and I've been on it ever sense I first laid eyes on Nancy.

Christian Horsdal (one of the people that first showed me Nancy) had written a book on Nancy in the style of Nancy. This is a great companion to every Nancy-developer. I love the bundling in  recipes and how they are "graded" in from Simple through Intermediate to Advanced.

I'm telling you for the last time - Marcus style

As most of you probably know I'm on my way to leave the country and do other type of work for a while. It's been a bumpy ride and we're actually still waiting for the work permits before we can leave. Any day now...

The last couple of weeks I've ended most of my commitments and different consultant contracts with my customers, but I don't have anything else to do... so I thought I'll make something up. Two things popped into my head:

• last year when I did some free presentations during a period between employments 
• and the fact that I don't want to come back in 3 years and just continue with the same material

From IMDB

Context injection of driver object in SpecFlow

SpecFlow is a wonderful tool. With a lot of hidden gems inside of it. I have been using and coding on it now for about 4 years and still I often forget about features and extension points that Gaspar and the community has put in there.

For example: did you know that there's an inversion of control framework built right into SpecFlow? Now you do and in this post I wanted to show you one way that you could use that feature to make your step definitions more maintainable.

I found this feature (again, i had heard about it before) when Gaspar mentioned it too me after my presentation at CukeUp 2013 and the usage is part of "Pushing the HOW down" which I wrote at length on before.

Nancy.Testing - executable specifications through the full stack, in memory

When I showed the code from the last post to a colleague (@HugoHaggmark), he remarked: Nice - but that no unit test. And he's absolutely right.

A unit test should test a unit. The tests in the last post, and the test that Nancy.Testing allows us to easily write, flexes the whole stack of our application. In memory (which is super cool) but the full stack. That's no unit test.

This can still be VERY useful and in this post I'll show you how to put one of my favorite tools, SpecFlow, in front of what we wrote in the last post, to get an executable specification. Not only that - I'll do it in a manner that let's you swap it and hit the HTML page if you wanted to.

As the tradition calls - let's look in wonder at Nancy's silhouette.
If you came here and want to read up on what we have spoken about so far, the other posts in the series can be found here:

1. Intro to testing with Nancy
2. The Configurable bootstrapper
3. The Browser and Response objects 
4. Hat and shoeless testing with Simple.Data
5. SpecFlow and Nancy(this post)

In this post I'll introduce you, short - very short, to Specification by example and SpecFlow and some practices that makes automating your application ... bearable   

Nancy.Testing - no hat, no shoes with Simple.Data

This is the fourth (oh my!) post in my series on Nancy.Testing. This time we will leave the Nancy.Testing specific stuff and let our gal meet a friend of mine: Simple.Data(.Testing). By marrying these kids together we will have a really cool full-stack-in-memory-testing-experience (FSIMTE it's gonna be a thing!).

I'll supply you with some background to Simple.Data and it's (awesome) testing capabilities, and I probably have to explain the title of this blog post, but then it's just code all the way down.

The other posts in the series can be found here:

1. Intro to testing with Nancy
2. The Configurable bootstrapper
3. The Browser and Response objects 
4. Hat and shoeless testing with Simple.Data(this post)
5. SpecFlow and Nancy

Let's dive right in a say hello to Simple.Data, if you haven't met him already. 

Nancy.Testing - testing (razor) views

I'm in the middle of writing a blog post series on Nancy.Testing and this bit me a bit (sorry, couldn't resist myself).

I have written a lot about how to test web-responses and all the great stuff that comes with it, but totally forgot about view. I assumed that it "just worked". And it does but... well read on. It's really simple.

Nancy.Testing - test-dialogues with Requests and Response

This is the third post in my series on Nancy.Testing. It will focus a lot of the Browser and the Response object. Together with the Browser (and it's ConfigurableBootstrapper) these objects makes up the entirety of the Nancy.TestingFramework.

Let's do the logo thing again, shall we?

The other posts can be found here:

1. Intro to testing with Nancy
2. The Configurable bootstrapper
3. The Browser and Response objects (this post)
4. Hat and shoeless testing with Simple.Data
5. SpecFlow and Nancy

By now you're probably just looking for the code so let's dive right in.

Nancy.Testing - configure her boot...strapper

This is the second post in my series on the awesome testability of Nancy - a minimalistic web framework on the .NET / Mono platform. Let's throw in the logo again - it so nice.

The other posts can be found here:

1. Intro to testing with Nancy
2. The Configurable bootstrapper(this post)
3. The Browser and Response objects 
4. Hat and shoeless testing with Simple.Data
5. SpecFlow and Nancy

This post covers a basic feature that makes up much of the awesomeness that is around configurability in Nancy testing: the configurable bootstrapper. 

There's a wiki-post on testing on the Nancy Github wiki but it leaves the ConfigurableBootstrapper with a mere mentioning. I think it deserves a deeper look, since you through this actually can control and swap out most anything from the Nancy framework. Even ViewEngines and the NancyEngine itself are possible to change to something that suits you better. In the testing case - we can supply fakes and mocks. 

Let's get to it - there's a lot of code to get through.

System.InvalidOperationException: No automation provider available MsTest and FluentAutomation

We’ve run into a little issue with FluentAutomation and using MsTest at my current client. I’ve blogged about the setup before but then I used NUnit and everything worked just fine. With MsTest… we had some problems. The first was an exception that was thrown to us like above:

System.InvalidOperationException: No automation provider available

It was a quite awhile since I’ve used MsTest and I’ve forgot about some of it’s quirks. With the combined help of Håkan Forss and Hugo Häggmark I managed to get this to work.

Scroll to the end for the short version, by the way.

SpecFlow.Assist.Dynamic–maxing out with Simple.Data

SpecFlow.Assist.Dynamic came about from my own need when I wrote something that used Simple.Data. I saw the power and simplicity (duh!) in Simple.Data by using dynamics. And I started to thinking on how it could be used in SpecFlow to further simplify and shorten up the code in my steps.
This is the third and final post on SpecFlow.Assist.Dynamic. Again this is not the formal documentation. It can be found here. These are just my personal preferences and thoughts on how to use it. This time with Simple.Data. And it won’t be long.

SpecFlow.Assist.Dynamic–what is it?

I have created my first ever NuGet package! I am so proud. Actually it’s just a small extension to SpecFlow and the excellent Assist helpers by Darren Cauthon. But I learned quite a lot about dynamics in the process and I thought I write a post or two on SpecFlow.Assist.Dynamic; what it is, the problem it solves and how it’s made. Later post will be around how to use it and to put it together with Simple.Data to create a real sweet testing experience.
Let me say – before I start – that there is documentation for usage on the GitHub wiki. This is a blog posts on how I made SpecFlow.Assist.Dynamic – not the official documentation.

Simple.Data–the testing story

I have fallen for Simple.Data. Big time. It’s so terse and concise that you almost lose the need for data access abstractions altogether. It’s just … there for you. Just see for yourself here. And when have this power at your fingertips it’s easy to forget the testing story.
How should I use Simple.Data so that I still can write unit and acceptance tests with code using it?
In my unit-tests I do not want to call the database, of course, because that would slow my unit-level tests down. Also if I do automated acceptance I want to go end-to-end, testing the full stack of the application. But there the database access will slow me down, often in the form of a network hop as well.
Have no fear! Mr Rendle have set us up with a couple of ways to mock out the actual call to the database on the lowest level, but still go through Simple.Data.
In this blog post I want to show you a couple of ways to write unit-tests that doesn’t hit the database, but still use Simple.Data.

Supported Step Exporter – watch your language

After working intensively with SpecFlow for a while now I have experienced something that I think is common. After a while you have all the steps you need… Or rather, if you write your step regular expressions carefully you’ll end up with a little language that automates the running of your application. So if you stay within the supported language you can simply write Gherkin. In Swedish for example.

It’s really cool to write Swedish that tells what the application should do. And it does it. I wrote about that experience before. The extension of this is that non-developers soon can start to write the specs and run them without any steps needed to be developed. But to do that you’ll need to have communicate which steps are supported.

Also after a while the supported regular expressions steps can be hard to remember. Even if you wrote all of it yourself. You soon start to want some kind of documentation for the supported regular expressions of your steps. But you don’t want to write that documentation. It’s a violation to the DRY-principle in my opinion.

The coolest thing would be if SpecFlow could give you some kind of Intellisense for the steps. But until then …

I have written a small console application that searches an assembly for the Given, When and Then attributes for SpecFlow and produces a very simple HTML-page. You simply point it to the assembly with your steps and give it a filename to create. Done!

You can now give that documentation to someone who cannot write the steps themselves, and they can just all those steps.

You’ll find the small SupportedStepExporter-application here, on Github, my new friend.

Changing endpoint from the command line when testing services with SOAPUi

I have been singing SOAPUi’s praises lately and it’s really great for testing services. In this post I describe how I made the whole thing work for testing WCF Services.
But, as stated in this post, there was still one more thing to be solved… The endpoints from the command line. You want to use different endpoints in different environments. And in my specific customer case I want one of them to stay the same all of the time, since that endpoint points (sorry, could not resist myself) to a “singleton” kind of service.
Luckily the SOAPUi team also have some great support (Thanks Ole, who replied in Swedish!). So here you have it – how to change the endpoint for one of your services under test from the command line – which in my case means the build script.

1. I first created a sample WCF service project (very vanilla, i didn’t touch the code just the default generated code).
   By the way; really cool hosting and test client stuff in Visual Studio 2010
2. I changed the binding to basicHttpBinding since that’s the only thing that work with SOAPUi. I used the WCF Service Configuration tool in Visual Studio of course.
3. I then created a normal SOAPUi project and let SOAPUi create testcases for me. I added asserts just to make sure that the I didn’t get an error back.
4. I started my service and ran the testcases – It worked!
5. I then, and here is the trick, created a project-wide property (Click project file and chose Custom properties in the lower part of the project window) to hold the endpoint value.
   
   1. I named the project wide property DemoServiceEndpoint
   2. I gave it the address of the service I was testing as value
6. I then opened the tree down to the test request in question and then chose the Test Property-tab in the lower part of the project tree
7. Here I entered this expression that reads the value from my project wide property:
       ${#Project#DemoServiceEndpoint}
8. I repeated for my other test request and tested. It still worked!
9. OK – we’re closing in now. Now I used the Test Runner to create my command (nifty stuff SOAPUi dudes!). Here I got the opportunity to set my parameter ${#Project#DemoServiceEndpoint}.
10. After some tweaking I managed to “harvest” the command into a .bat-file.
    
    

    "C:\Program Files (x86)\eviware\soapUI-3.5\bin\testrunner.bat" -sDemoTestSuite -PDemoServiceEndpoint=http://localhost:8732/Design_Time_Addresses/Marcusoft.SOAPUiDemo.WCFService/Service1/ C:\Dev\Marcusoft.SOAPUiDemo\EndPointOverrideDemo-soapui-project.xml 

    
    
11. And it worked!

So now I can change the endpoint from the command line! In my build script when I have deployed the service to the testing environment for example! Yeah!

You can download my example here.

Vb.net considered harmful

I have once again been forced into using VB.NET which I am not very fond of.

My points up to now has been that the language in itself is not that bad. But the support (refactoring etc.) in Visual Studio is much worse than for C#. Also, there is a culture in the VB.NET community (as I understand) to hide complex stuff from your user. So for example you cannot see the references you have in your project until you hit “Show all files”. Another example for the sub-par support you get when using VB.NET.

My final point up to now is that the most common reason to chose VB.NET over C# is that you have VB6-programmers that is to be converted into VB.NET programmers. The problem is that VB.NET automatically (yeah, you can and SHOULD turn it off) include the Microsoft.VisualBasic in all new projects. Which gives you the possibility to continue using Visual Basic syntax and commands, such as CLen(“a string”) and completely miss the OO point in .NET framework.

You could argue that all this is opinions by me. And maybe it is, but as more advanced stuff was and is being introduced into in .NET Framework (from 3.0 and forward) VB.NET is cracking down according to me.

Lamdas and anonymous methods for example is suffering heavily from VB.NET demand on typing all parameters and the fact that you have to use a “_” as a line ending when formatting long lines.

Take a look at these two examples, from the Moq Quickstart:

C#

VB.NET

I used the Developer Fusion C# to VB.NET conversion tool to translate the code as I cannot make it by hand in VB.NET. I fail every time. I also used pastie to shared the code. It doesn't support VB.NET syntax. Sorry for that.

What we now have is the language obstructing you and confusing you with syntax. That makes the whole concept harder to understand – and it’s quite hard to grasp from the outset for VB6-developers.

So from my point of view VB.NET makes your program harder to read and understand, and you have lesser support in Visual Studio (don’t know about MonoDevelop) and finally it includes all of Visual Basic so you stand the risk that your developers use non-standard syntax and commands.

Trying Coding Dojo, Kata and Extreme OOP

In preparations for a presentation next week (which will go on for two days… brrr) I had my sights set on doing something about Extreme OOP or Object Calisthenics. I’m thinking of using that exercise to illustrate some OOP practices.

In the PDF-file for the Extreme OOP above you’ll find an excellent kata (the Commodore 64 kata) that will take you through all the rules of Object Calisthenics.

OK – but since I didn’t wanted to do that exercise all of my own I hooked up with two Avega colleagues (David Blomberg and Magnus Forberg, great guys!) and we did some kind of coding dojo.

The findings was quite surprising.

• First – the rules of Object Calisthenics are not be followed when you do ordinary code. It’s simply an exercise to get you to think about OOP in a very structured fashion.
• Secondly – the rules are very hard to follow… Very hard. We didn’t get quite there I felt.
• Thirdly – the main take-away for me was that you learn so very much by doing pair programming and TDD together. It’s simply the best way to code in my opinion. The amount of information that is transported back and forth for each code line is immense. I almost don’t dare to do code on my own ;)
• Fourth – just by sitting next to another person coding is a great learning experience. Shortcuts, patterns, tricks and structuring solutions – everything you can think of. And it sticks.

So – I still think the exercise was good – but it didn’t get to what I thought and I learned a lot of stuff that I didn’t thought either. Thank you guys.

First stop for learning events, delegates and anonymous methods

I found this great article about events, delegates and anonymous methods.

I always get lost in these matters and now-a-days you can have some really funky syntax with lambdas and everything (I mean who can honestly say that: “() => { }” is read- and understandable. Honestly).

OK – this guy (can’t find his name) has done an excellent write-up, with lots of links to other places if you want to go deep (but that’s really deep, bottomless if you want).

Simple but useful generic repository pattern

I have pointed here several times before – but it’s so nice.

It’s an implementation of the Repository Pattern using generics, that will minimize your code in a very nice way. I am sure that the FindAll can be refined into something very nice with LINQ, that allows you to send a specification criteria or so.

Here is my implementation that uses a common interface (IBaseEntity) for all my entities. It basically has an ID, so that the abstract implementation can use it as a key:

namespace Marcusoft.SprintPlannerHelper.Repositories
{
    /// <summary>
    /// A generic repository interface that dictates all the methods that a repository should map to
    /// </summary>
    /// <typeparam name="T">the type of the interface</typeparam>
    public interface IRepository<T>  where T :IBaseEntity
    {
        T GetById(Guid id);
        IList<T> FindAll();
        void Add(T entity);
        void Remove(T entity);
    }
}

 

public abstract class Repository<T> : IRepository<T> where T : IBaseEntity
{
    protected readonly Dictionary<Guid, T> dictionary = new Dictionary<Guid, T>();

    #region IRepository<T> Members 
  
    public T GetById(Guid id)
    {
        return dictionary[id];
    }

    public IList<T> FindAll()
    {
        return new List<T>(dictionary.Values);
    }

    public void Add(T entity)
    {
        dictionary.Add(entity.ID, entity);
    }

    public void Remove(T entity)
    {
        dictionary.Remove(entity.ID);
    }

    #endregion
}

 

public class ProductRepositoryFake: Repository<Product>, IProductRepository
{
    /// <summary>
    /// Default constructor that fills the repository with some testdata
    /// </summary>
    public ProductRepositoryFake()
    {
        // Add the products from the testdata-class
        foreach (var p in TestData.GetTestProductList())
        {
            dictionary.Add(p.ID, p);
        }
    }
}

I implemented it and wrote this with Albert sleeping on my chest. Just imagine if all programming sessions were so peaceful.

Snippet for creating testmethod in C#

Here is a short snippet that saves me a lot of time. It simply creates a test method with the correct attributes and stuff. Simply but useful – and now you don’t have to write it.

<?xml version="1.0" encoding="utf-8" ?> 
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet"> 
    <CodeSnippet Format="1.0.0"> 
        <Header> 
            <Title>TestMethod</Title> 
            <Shortcut>tm</Shortcut> 
            <Description>Code snippet for creating a testmethod</Description> 
            <Author>Marcusoft (www.marcusoft.net)</Author> 
            <SnippetTypes> 
                <SnippetType>Expansion</SnippetType> 
                <SnippetType>SurroundsWith</SnippetType> 
            </SnippetTypes> 
        </Header> 
        <Snippet> 
            <Declarations> 
                <Literal> 
                    <ID>methodName</ID> 
                    <ToolTip>The name of the test</ToolTip> 
                    <Default>methodName</Default> 
                </Literal> 
            </Declarations>           
            <Code Language="csharp"> 
              <![CDATA[<TestMethod()> _ 
              public void should_$methodName$()
             { 
        // Arrange 
        
        // Act

        // Assert 
        Assert.Fail("Implement test"); 
    }]]> 
            </Code>  
        </Snippet> 
    </CodeSnippet> 
</CodeSnippets>

Sprint Planner Helper – Session 3

As I reviewed my work from yesterday I quickly realized that I bit off much to much. I only need to implement the model for the first product backlog item which is:

As Product Owner I can create a product backlog so that the team knows what is left before the product is done.  Each product backlog item requires at least an ID, description, priority.  Optional are story points (how big is this compared to other) and the possibility to upload a  document with additional business rules

So - true to the XP guidelines to not do more than is absolutely minimum to solve the task at hand, I backtracked and removed a lot of the code I wrote yesterday. I want to see where the TDD and Extreme OOP takes me.

I start each session by reviewing those rules in order to really get them to stick. Man - they are though ("Don’t use any classes with more than two instance variables", gulp).

OK - so what I managed today was simply to get my model for the first story up. Great! I am getting a hang of the TDD-ing. I have also fallen back in love with C#. What a nice language. And the support for TDD in Resharper is great (with the Create Field on other class helper for example).