This is a follow up on a post from Typemock Insider, Unit Testing – What not to test…

You should test everything! except when you’ve got a good reason not to. One of the most common reasons for me is “testing this will not add any value, just increase complexity and coupling between my tests and system under test”.

I hear a lot of other reasons not to test that I can’t find legitimate

• It’s too complexThis is the best reason to test, but I’ve heard this argument from several developers. When it is too hard, they won’t put their mind to it. Quite often they write bad tests that just run through the code and make sure it doesn’t throw any exception at them. That if something is a useless test.

  Instead, you should refactor until the code is not too complex to test. That will add a lot of value to the whole system.

• It’s built on EPiServer (or Sharepoint, or Umbraco, or [insert your framework here])This is just a crap excuse for lazy programmers. You’re nothing but one google result away from learning how to combine unit testing with any framework.
• It’s all frontend magicThen maybe unit tests aren’t the way to go. There are other kind of tests that will deal with the complexity of frontend logic. You can use frameworks like WatiN or Selenium. There’s Web Test from the Microsoft Team Suite that will also do the trick.

  You should also be considered with not putting too much logic in your frontend layer. When you feel the need to unit test your frontend logic, you probably have the need to refactor down the logic,  one more layer of abstraction.

• It’s too simple, there’s no logicIf you have a facade with the only purpose is to call another layer, you might not want to write a unit test for each method in the facade and make sure that method calls the next layer. What you can do, is to write an integration test that looks on every public method in this layer and makes sure that it calls a method in the underlying layer. This is not a unit test, but rather a constraint put on the architectural design.

  You can accomplish the same thing by setting an NDepend rule on the build server. That could be complementary to the test and should yield the same result.

If you’re unsure, write the test. After a while you might come to the conclusion that the test is useless and then remove it.

“If you hand roll your SQL statements you’re stealing from your clients.”

That is the essence of what Ayende is saying and I dearly wants to suppose he’s right. I love the idea of a layer of abstraction over the database, bridging the relational world to the object oriented. But every time I’ve tried to setup NHibernate I’ve failed with even the most basic scenarios, and it pains me greatly knowing what’s right but not getting it to work. I think the main issues are the following.

• I’m a beginner looking for a silver bullet, but everytime I rip someones implementation and try to adapt it to my own situation I fail because every scenario seems to need its own custom solution.
• Every time I search google for a solution to my problems, I only find articles with lingo I don’t understand or so advanced that it’s useless for my simple task. (NHibernate in F# anyone?)
• When you read a discussion between the leading ORM specialists in the field they never ever agree on anything. Generic repositories, entities as domain model or how to handle the session factory. For every strong idea there seems to be an equally strong opposition.
• It’s not intuitive. Today I got a very cryptic exception that turned out to be that I forgot to add an Id-property to my entity. I guess that the exception message was refering to the abstract faulty state that was going on, but a google search turned out the most common failure. The whole framework seems to suffer from the same problem of expressing itself in what is correct and not what’s easy to understand.

I will get there. After hours and hours of fighting with errors I will at last feel proficient enough to use it in an application for a client. Until then I’ll worry about how every Joe Developer will manage to do the same thing and start traversing that learning curve.

In the middle of my project, the client sends me this excel file that I should validate user input against.

I asked around among my colleagues to get their opinion of what I should do with this treacherous thing. Their answers were any of

• Import it into an SQL table and query against the database
• Give the client a web page where they can upload it, and transform the file to XML

Programmers doesn’t like Excel as a data format because it is an unreliable grid where anything could be a text, numeric or date value. There is nothing short of convention of how columns are placed and ordered on the spreadsheet;  a complete nightmare.

I decided to take on the challenge. We all know that this customer will come back with an updated spreadsheet in the future, and then I would like to just replace the old one.

I know that you can use OLEDB connections to query Excel documents with SQL-like queries, but I wanted something cleaner. What I found was LINQ to Excel, which is really an outstanding idea. Look at the following example.

First I create my model object that represents a row in the spreadsheet.

public class ZipCodeWorksheet
{
    public const string Name = "Report";

    public string Country { get; set; }
    public string ZipCode { get; set; }
    public string City { get; set; }
}

Then I write the LINQ query.

var repo = new ExcelRepository(this.filePath, ExcelVersion.PreExcel2007);

repo.AddMapping(x => x.Country, "COUNTRY");
repo.AddMapping(x => x.ZipCode, "ZIPCODE");
repo.AddMapping(x => x.City, "CITY");

var q = from worksheet in repo.Worksheet(ZipCodeWorksheet.Name)
        where worksheet.ZipCode == indata
        select worksheet;

Easy, maintainable and your clients will love you for it.

I love the Thickbox. It’s fast, easy to use and I’ve not had any problems with it, until today.

I added an ASP.NET UserControl to a page. This user control was a form where readers should be able to submit comments. Additional to scrolling down to the bottom of the page, I wanted to make the form available in a thickbox. However, as soon as my form was in the whitebox window it stopped responding to ASP.NET events, such as button click.

The reason for this was simple. When the thickbox window opens it will copy the content to a new node called TB_window under the body. This won’t work with ASP.NET UserControls because they have to stay inside the server form tag. Otherwise, events will not be triggered. Since I did not want to load my user control inside an IFrame, I opened up the thickbox.js and did some modifications.

1. Give your server side form tag some ID, mine is aspnetForm
2. In the thickbox.js, modify every code that adds or remove stuff from the body, to #aspnetForm instead.

I think this might be less stable than just adding the elements to body and I’ve not tried it in Internet Explorer 6 yet. The solution seems promising though.

Here’s my code as reference when you do your own mojo.

Fifteen years has passed on the Internet.

I started out using the Internet 1994 when it was hard to get your own e-mail address and the most popular website in Sweden was the Aftonbladet (newspaper) chat room. It was a time of Internet Explorer 3.01 and Netscape Gold, the better browser that lost the war.

Interestingly enough, this was the time when every company recognized that they got to be on this new thing, called the Internet. When I look at my clients today they are on their third generation of websites, which means that they have rewritten their website every fifth year.

Why is a complete rewrite needed every fifth year?

• We’re not rebuilding buildings every fifth year.
• We’re not re-planning cities every fifth year.
• We’re not recreating organizations every fifth year. (but maybe we should)

The reason we’re rewriting software every fifth year

• The world around our applications change so rapidly that they become obsolete in five years. That is why the Aftonbladet chatroom has closed down, because they couldn’t keep up with technology.

In what way do our solutions differ today from those written fifteen years ago? It’s still web pages, HTML/CSS served by web servers and the HTTP protocol.

• Applications degenerate from the change management enforced upon them. Every time we make a change, the application becomes harder to change until a complete rewrite is needed.

This is the largest failure of the IT industry today.  Not being able to handle change in an ever changing world is a sign of how immature our business really is. You can measure quality of any application on how well it responds to change.

• - My clients expects a complete rebuild every fifth year, and that is why we only build it to last for fifth years. (a consultant speaking)

While buildings are built to last for 100 years, software is built to last five. There is a mindset here that software only last five years and instead of facing this problem, we accept that a new investment has to take place five years from initial release of a new website.

Consulting is a special case where you’re hired by a client that does not want their own IT production department. They most often give you limited time and limited budget and expect you to deliver them a set of features, which adds up to the evil triangle where one promise has to be broken.

What has to be cast aside is the quality in order to keep that promise, and that results in a complete rewrite in about five years, because this product was not meant to last. You will argue that agile development is the solution to the evil triangle, but from my perspective it’s only dividing the problem into smaller parts, buying the consultant firm a “get out of jail free card”.

Please give me the resources to write applications that would last for 10 to 15 years. Let me write pluggable interfaces that could be upgraded with a new design that matches the current trend every three years, without affecting the business model. Let me write generic data persistence where the DBMS could be upgraded to SQL Server 2018 without major impact on the application. Let us define a domain model that is easy to change as the business rules adapt to the world that spins round every 24 hours.

Please let go of the 5 year mindset and focus on 20 to 100 years.