Run xUnit in hosted Team Foundation Service

Now, as promised my other project is hosted and built on hosted Team Foundation Service and it took me a bit of fiddling before I managed to run NUnit tests on it. However, there is an excellent walk-through how to do that: http://www.mytechfinds.com/articles/software-testing/6-test-automation/72-running-nunit-tests-from-team-foundation-server-2012-continuous-integration-build

Much in the same way you can do xUnit:

  1. Download xunit.runner.visualstudio-x.x.x.vsix from Codeplex.
  2. Change file extension from .vsix to .zip and open with zip archiver.
  3. Copy all xunit.*.dll files to a folder that is mapped to TFS and check them in. I prefer to have these files in /BuildFramework folder

xUnit_VS

  1. Now, pretty much the same as with NUnit set up (If you have not done that before), you need to update settings for Build Controller. In VS go to Team Explorer -> Builds -> Actions -> Manage Build Controllers. And set “Version Control path to custom assemblies” to the folder where you have saved adapters for xUnit:

Build_controller

And you are pretty much done. You can now check in and your xUnit tests will run on hosted TFS (Presuming TFS is set up correctly to run your tests).

Convert your projects from NUnit/Moq to xUnit with NSubstitute

UPDATE: After initial excitement about xUnit, I needed to deal with some specifics. And now I don’t advise to move ALL your tests to xUnit. I’d recommend go into that slow and read through my rant here, before you commit to converting.

Nunit is a great testing framework. Only it is a little old now and new testing approaches are no longer fit into Nunit concepts. I’m talking about using Autofixture for generating test data. So I decided to see how xUnit will pan out for our projects and should we convert all our tests into xUnit or not.

Benefits of xUnit over NUnit are simple for me: AutoData attribute from Autofixture does not play nicely with NUnit due to architectural wirings. There are ways to have Autodata for
Nunit
, but this does not work nicely with Resharper 8.1 and NCrunch.

Continue reading

Bundling all your assemblies into one or alternative to ILMerge

Before today I’ve heard of IlMerge tool. This allows you to bundle all your small .dll files into one. So if you deploy stand-alone applications, you only have to give a single file to your users. Today I decided to give it a go. And I was disappointed -( error messages were endless. IlMerge did not like this or that or some other assembly.

I quickly looked around and found Costura.Fody package that did exactly what I needed, only I did not have to do any work. All you need to do is install nuget package:

Install-Package Costura.Fody

And you are done. No, really. Build your project and check out the output. You’ll see a bunch of dll files as before. This is because input files are not deleted automatically. But if you check your executable – it is much larger now. And you can move it away from the rest of libraries files and it will work.

There are some settings available. Check the details on https://github.com/Fody/Costura.

Package installation will create FodyWeavers.xml file in the root of your solution – put your settings there. I needed to exclude debug symbols from the resulting file. Here is how my FodyWeavers.xml look like:

<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
  <Costura IncludeDebugSymbols='false' />
</Weavers>

Also I did not care about “minifying” the libraries into one file when I built the debug, but I needed it for Release build. So in my .csproj file, at the very end I have this:

  <Import Project="Fody.targets" Condition=" '$(Configuration)' == 'Release' " />
  <!-- Below is the clean-up - removing the input dll files-->
  <Target AfterTargets="AfterBuild;NonWinFodyTarget" Name="CleanReferenceCopyLocalPaths" Condition=" '$(Configuration)' == 'Release' ">
    <Delete Files="@(ReferenceCopyLocalPaths->'$(OutDir)%(DestinationSubDirectory)%(Filename)%(Extension)')" />
  </Target>

By default the package only adds one line:

  <Import Project="Fody.targets" />

And usually this is good enough. But I’ve added checking for build type and also my OCD required to produce a clean output folder. All this is explained on the GitHub page, on the very bottom.

Overall, very nice package! It just works.

Speed up Editing of Cshtml Razor files in Visual Studio: Resharper vs Web Essentials

Lately I’ve experienced a very slow editing on Razor pages in Visual Studio 2013. I had a set of extensions installed, but nothing special: Resharper 8.1, Web Essentials and VSCommands. When I was editing Razor .cshtml file, every keystroke was painfully slow, especially when I was trying to edit C# code there: we have a lot of helpers and html generation tools, our view are almost html-free, only control builders.

Long story short, by disabling extension one by one, I’ve narrowed down the performance issue to Web Essentials setting that tries to auto-format HTML.

To fix that in Visual Studio 2013 go to Tools -> Options; select Web Essentials section and HTML sub-section; and disable Auto-format HTML on Enter:

web_essentials

IHtmlString and what it can do for you

IHtmlString and what it can do for you

Start of this year, we have been working very hard on converting our MVC application from free-flowing Html in our Razor views to helper based templates. The ultimate goal is to be able to change one template and the rest of the application will follow the example. And with free-flowing HTML you can’t do that easily.

Continue reading

Uploading large files to Azure Blob Storage through REST API

I did write about uploading files to Azure Storage via REST API before. It turns out that implementation is very naive. As soon as I tried uploading anything larger that 64Mb, I hid a brick wall with exceptions.

Azure Blob Storage has 2 types of blobs: Page Blobs and Block Blobs. Page Blobs are optimised for random read-write operations. Block Blobs are storage. Here more about Page vs Block blobs. If you are just storing files in Azure, you’ll most likely will use Block Blobs.

It turns out that Block Blob storage has some limitations on the upload front. In one go you can upload up to 64Mb: 1024 * 1024 * 64. Add one extra byte and you get an error from the API (I
tested it). So instead of uploading large files, you need to cut them into blocks and then upload separate pieces of no larger that 4Mb. And once all the pieces (Blocks) are uploaded, you need
to commit them all and give order in which they should appear.

Continue reading

Asp.Net MVC ViewBag is BAD!!

Being on holidays gives me a lot of time to go through MVC questions on StackOverflow. And a lot of questions come from misusing of ViewBag and ViewData. A lot of people leave out Model from MVC and just slap all their data into ViewBag. And this is bad.

I can understand why people are lazy: [sarcasm] creating an extra class can be very problematic, takes a lot of keystrokes [/sarcasm]. What people don’t realise is that ViewBag make them work harder.

ViewBag is a dynamic entity and it can contain any property it likes with any type it likes. So every time you do in controller something like this:

    public ActionResult SomeViewBagAction()
    {
        ViewBag.SomeText = "blah";
        return View();
    }

Continue reading

Test for default constructors in models for Entity Framework

Entity Framework relies on models to have a default constructor with no parameters. But if you are working with DDD often you would like to have some parameters in your constructors. And then slam a protected default constructor just for EF not to throw exceptions.

So you end up with code like this:

public class Product
{
    protected Product()
    {
        // This is required for EF
    }

    public Product(String name)
    {
        Name = name;
    }

    public String Name { get; set; }
}

The first constructor must not be used by developers, so you make it protected – this is good enough for EF.

Continue reading

Test all you queries to have handlers

CQRS architecture seems to be very popular. And I’m on that wave as well. In short CQRS is separating all read-actions from write-actions. And you have different classes for reading and writing. Queries for reading. Commands for writing.

For queries you would have IQuery and IQueryHandler interfaces:

public interface IQuery<out TResult>
{
}

public interface IQueryHandler<in TQuery, out TResult> where TQuery : IQuery<TResult>
{
    TResult Handle(TQuery query);
}

For command you would have very similar set of interfaces:

public interface ICommand
{
}

public interface ICommandHandler<in TCommand>
{
    void Handle(TCommand command);
}

Continue reading

Test Your IoC Container

There are doubts about if you should test registrations in you IoC container. I have been intimidated by this blog-post for a while and did not touch container for writing our tests. However, we did have a problem in the past, when DI container could not create one of our controllers. And we have lost days trying to chase the problem – there was no meaningful error message, because the real exception was swallowed somewhere in transit. It turned out that we have violated DI principal of a simple constructor: “Do nothing in constructor”. I have blogged about this before.

Today I would like to show how we test our IoC container to check if it can create all our controllers. Because controllers are immediate aggregate roots that are used by an end user. And controllers in MVC are the final consumer in the dependency chain. So if you likely to hit a problem in a chain of dependencies, it is likely that you will catch it by creating all the controllers.

Of course, if you use IoC container as a service locator or Mediator pattern you will have to test container separately for the types you get out from container there (mostly Command Handlers and Query Handlers).

Continue reading