We don’t have time for unit tests

This is probably one of the biggest bullsh*ts people usually tell in the world of software development:


I’ve heard it many times before, and I bet you’ve heard it too. I was unfortunate enough to work for companies where PMs and other people had this mentality, even giving the impression that unit tests were a waste of time. “Just do it quick and dirty” – this was a very common sentence in one of the last companies I worked for.

A lot has been written about unit tests in the last 15 or 20 years, and the advantages should be obvious by now – you can refactor your code with confidence without the fear of breaking existing functionality, you can run unit tests as part of an automated build, and so on.

But there are disadvantages as well – you do need to spend some time to write the test and debug the piece of functionality you’re testing, as obvious. This is usually the excuse given for NOT writing unit tests. But the truth is that we need to test the functionality somehow – it’s not acceptable to write a piece of code without testing it, right? You simply have to test your code, one way or another – even if you don’t use unit tests.

That leaves me with another question – from a development perspective, do you think that the alternatives ways to test your code are faster than writing a unit test? I don’t think so. I still believe that unit testing is the fastest way to do it, if you have a decent enough experience with it (you don’t need to be an expert, though). Let’s analyse the following scenario below.

The scenario – discount calculator

Imagine that you are working on an e-commerce website – the UI is an ASP.NET website that uses a REST API (ASP.NET Web API), where all the business logic is. You need to implement a discount calculator in the API, based on the customer type:

  • Platinum (20% discount)
  • Gold (10% discount)
  • Silver (5% discount)
  • Standard (no discount)

Source code would be something like this:

public interface IDiscountCalculator
    decimal Calculate(decimal productPrice, CustomerType customerType);

public enum CustomerType
    Standard = 0,
    Silver = 1,
    Gold = 2,
    Platinum = 3

So let’s examine some of the different ways we could test the discount functionality.

1. Testing using the UI (website)

In this scenario you basically need to run the website and the API, and navigate to the page where the discount is being displayed (e.g. view shopping cart). This means that you might eventually need to login, search for a product, add it to the shopping cart and then view the shopping cart in order to check if the discount is correct or not. Also, you need to do it for each customer type.

As you can imagine, this is not the most efficient way to test this functionality. We need to compile and run both the website and the REST API (authenticate user, etc).

2. Testing the API using a REST client

This is more efficient compared to the previous example (testing the UI) because you can skip all the steps mentioned before and invoke the service using a REST client such as Postman or SoapUI. You still need to create sample HTTP requests that might include HTTP headers (content type, authorization, etc), HTTP method and message body (JSON request object).

Depending on the service, it might take a while to configure the requests for each customer type. Also, we need to compile and run the REST API. Remember that in this scenario all we want to do is to calculate the discount for each customer type.

3. Testing using a console application

This is one of the simplest ways to run the test. There’s no need to use the UI to get to the page where the discount is displayed and there’s no need to create HTTP requests in order to invoke the API, i.e. we can test directly the discount functionality using .NET code. Also, console applications are faster to compile and run compared to an ASP.NET website.

4. Testing using an unit test framework

It’s basically as simple and fast as creating a console application – just add add your unit tests to a class library and you’ll be able to run the tests in a few seconds, using Visual Studio built-in functionality or a tool such as Resharper.


Saying “we don’t have time for unit tests” is deceiving. Giving that we need to to test our code somehow, ask yourself if the alternative to unit tests is easier and/or faster (creating a sample console app to run some tests, etc) – I’m pretty sure that in most of the cases the unit testing is the better option.


Re-throwing exceptions without losing the original stack strace in .NET

This is nothing new – if you need to re-throw an exception in a catch block without losing the stack trace you use the throw statement like this:
01 throwThings are a bit different outside a catch block, though. Consider the following code sample:

Just to give you some context, this excerpt is from a MessageHandler that I implemented to log HTTP requests and responses in a ASP.NET Web API application (based on Log message Request and Response in ASP.NET WebAPI). I have an ExceptionHandler class that will log all unhandled exceptions, that’s why I’m re-throwing the exception here.

The problem is that the following command will instantiate a new exception and clear the original stack trace:

throw exception;

Fortunately there is an easy fix. From .NET v4.5 you can use ExceptionDispatchInfo class to capture the current state of an exception and re-throw an exception without changing the original stack-trace:

That’s it! Happy coding 🙂

Visual Studio: Unable to start debugging on the web server

This happened to me today – I was getting the same error whenever I tried to debug an ASP.NET application using Visual Studio:

Unable to start debugging on the web server. Could not start ASP.NET debugging. More information may be available by starting the project without debugging.


My initial reaction was to check if there was something wrong in IIS, and I was right: the application pool used by the application I wanted to debug was stopped!


At that moment I realised that I changed my Windows password 2 or 3 hours before trying to debug the application. Given that the application pool was running under my credentials, all I had to do to fix the issue was to right-click the application pool and go to Advanced Settings > Identity and update my password 🙂


ASP.NET: Downloading files from a UNC share

Implementing a cross-browser solution for downloading files from a UNC share in ASP.NET applications

Table of contents

The scenario

I was working recently in an intranet application that had a download page. The output HTML was similar to the following:

<li><a class="download" href="\\MYSERVER\reports 2011\report1.zip" title="Report 1">Report 1</a></li>
<li><a class="download" href="\\MYSERVER\reports 2011\report2.zip" title="Report 2">Report 2</a></li>
<li><a class="download" href="\\MYSERVER\reports 2011\report 3.zip" title="Report 3">Report 3</a></li>
<li><a class="download" href="\\MYSERVER\reports 2011\report 4.zip" title="Report 4">Report 4</a></li>
<li><a class="download" href="\\MYSERVER\reports 2011\report 5&6.zip" title="Report 5&6">Report 5&6</a></li>

This was working fine in IE9, but not in other browsers. There was no action using Google Chrome, and using Firefox there was an error (HTTP Error 400 – Bad Request).

I tried to convert the file path to a file URI but it didn’t fix it. It continued to work on IE only.

<li><a class="download" href="file://MYSERVER/reports 2011/report1.zip" title="Report 1">Report 1</a></li>
<li><a class="download" href="file://MYSERVER/reports 2011/report2.zip" title="Report 2">Report 2</a></li>
<li><a class="download" href="file://MYSERVER/reports 2011/report 3.zip" title="Report 3">Report 3</a></li>
<li><a class="download" href="file://MYSERVER/reports 2011/report 4.zip" title="Report 4">Report 4</a></li>
<li><a class="download" href="file://MYSERVER/reports 2011/report 5&6.zip" title="Report 5&6">Report 5&6</a></li>

The solution was to create a custom ASP.NET download page. I used also jquery on the client side.

Step 1: Using jquery on the client side

The first step was to add an event handler to the download links. The request URI is encoded and is sent as a parameter to the download page. Creating an hidden iframe and setting the src attribute with the download link allows the file to be downloaded asynchronously.

$("a.download").bind("click", function (e) {
    var requestedFile = encodeURIComponent($(this).attr('href'));

    var iframe = document.createElement("iframe");
    iframe.src = 'Download.aspx?file=' + requestedFile;
    iframe.style.display = "none";
    document.body.appendChild(iframe); // triggers download page

Make sure you use encodeURIComponent function to encode special characters in the filename.

Step 2: Create an ASP.NET download page

This is the source code of the download page:

protected void Page_Load(object sender, EventArgs e)
        string requestFile = Request.QueryString["file"];

            throw new FileNotFoundException("File to download cannot be null or empty");

        // Get file name from URI string in C#
        // http://stackoverflow.com/a/1105614
        var uri = new Uri(requestFile);
        string filename = Path.GetFullPath(uri.LocalPath);
        var fileInfo = new FileInfo(filename);

            throw new FileNotFoundException("File to download was not found", filename);

        // get content type based on file extension. Example:
		// http://stackoverflow.com/a/691599
        Response.ContentType = GetContentType(fileInfo.Extension);

                           "attachment; filename=\"" + fileInfo.Name + "\"");
        // ignore exception
    catch(FileNotFoundException ex)
        Response.StatusCode = (int) System.Net.HttpStatusCode.NotFound;
        Response.StatusDescription = ex.Message;
    catch(Exception ex)
        Response.StatusCode = (int) System.Net.HttpStatusCode.InternalServerError;
        Response.StatusDescription = string.Format("Error downloading file: {0}", ex.Message);

Some notes:

This is necessary in order to make the download work with a UNC share (\\MYSERVER\….) or a file URI (file://….)

    var uri = new Uri(requestFile);
    string filename = Path.GetFullPath(uri.LocalPath);

To avoid filename truncating, it’s necessary to wrap the filename with quotes

                       "attachment; filename=\"" + fileInfo.Name + "\"");


Technorati Tags: , , ,