VS2012–Testing My Patience

Another thing I’ve come across in Visual Studio 2012 is the new Test Explorer.

Where the Solution Explorer has gone from strength to strength, the Test Explorer has gone backwards.

Let’s look at the group by option in Visual Studio 2010:


Now let’s see how this has improved in Visual Studio 2012’s Test Explorer:


Okay, I know you’re working on it Visual Studio team. Release the new one in version 2011SP1 if it’s not ready. But you’ve actually killed the testing functionality in VS2012.

I used the class name as a functional part of the test, so the group by enabled me to find a set of tests related to a class, focus on those and move on.

My VS2010 grouped list looks like this:


Here is the same project in VS2010:


Now I have a sea of similarly-named test methods and no clue which one does what because I’ve lost the context of the class and project it relates to.

I have to consider renaming all my tests. Or switching back and doing my testing is VS2010 – which is exactly what I do.

Yes, I know the VS2012 team is aware of this and are planning to do something. But it’s like they removed the stairs from my house to fit a lift (elevator for those in the US) but didn’t finish the job. I’ve moved in and now have to get upstairs by climbing the scaffolding.


Since this original post, the Test team has since included the updates to the testing functionality in Visual Studio 2012 Update 1 so that you can now group by module and ‘traits’ (TestProperty attributes in VS unit tests). Thank you VS TestTeam – finally I can retire VS2010!


VS2012 – Fifty Shades of Grey

There are lots of good and interesting things in Visual Studio 2012, but there are (as always) some negative points.

Grey Greyer Greyest

I still hate the new bland UI colour scheme. It’s like a minimalist architect got hold of the Victorian Gothic that was VS2010, and removed everything.

That is a personal, aesthetic viewpoint and some people must love it, but this new bland UI is actually bad from a practical, functional viewpoint.

Why Icons?

I’m ‘old school’ so I remember what apps were like before icons. WordPerfect and Lotus 123 had no GUI, so text was all you had. Finding commands among the sea of text was hard because (unless you learned their location through experience) you had to read each text entry to figure out what it was.

Icons were introduced to get rid of load of text and provide a shortcut: to make it faster to find the command you needed. People can see and filter a lot of pictures much faster than words. To quote Wikipedia (my emphasis):

The icon itself is a small picture or symbol serving as a quick, intuitive representation of a software tool, function or a data file accessible on the system

Why VS2012 Got It Wrong

In this respect the new icons work against you. Microsoft has reintroduced a little splash of colour in some, but it’s grudging and barely visible except up close.

Take this example, where we compare VS2010 and VS2012 toolbars:


Now the challenge: find the previous bookmark icon

VS2010: image

VS2012: image

How did you fare? Chances are that the VS2012 took longer because all the icons are very similar and the colour hint is so subtle as to be almost pointless.

The pale blue is dominant in the VS2010 icon so you can visually filter out most of the icons because they are obviously different. In VS2012 the dominant colour is black, as it is in most of the icons.

It would seem that now VS2012 favours form over function.

It Doesn’t Stop There

Okay so the icons are rubbish. What about the fifty-shades-of-grey scheme? Well if that’s what the design team like fine, but why just two options? Why not allow us to customise it?

The designers have tried to flatten out the interface and remove all the borders. I can almost hear the design meeting: “too much visual clutter!”

So they threw out the baby with the bathwater and removed all the boxes. So now the menu, the icons, the tabs and the toolbars all float together in design nirvana.

So, like a farm where all the hedges were removed, everything visually wanders about and the menu and icons and workspace all tend to blur together.

“I know!” pipes up a junior member in the design meeting, “what if we make all the menu commands in CAPS? Then it’ will be easier to make out!”

And so it came to pass.

Roll on, VS2014.


Thankfully I’m not alone, and there are now extensions to alleviate the worst of the VS2012 UI:

Visual Studio 2012 Color Theme Editor

and even

Visual Studio Icon Patcher

The colour editor seems to work fine. The icon patcher requires both 2010 and 2012 installed and is a a first beta, so you may not want to try that out.

Give it a REST please

I attended DDD10 this weekend and among the presentations was one by Jacob Reimers called Taking REST beyond the pretty URL.

Jacob’s Case

Jacob’s contention here was that the examples of MVC that use actions in the URLs were an improper use of a REST approach.

His "’bad’ example was a simple bookmarks application. The URL /Bookmark lists all bookmarks and /Bookmark/{id} should represent the bookmark resource. Editing a bookmark in the original application was done via /Bookmark/Edit/{id} and there was /Bookmark/Details/{id}

His argument here is that Edit is an action and we should not be doing this via the URL, we should use a HttpPost verb on the same URL. He shows that sending a HttpGet to the MVC URL with “accepts: application/json” should return JSON and not HTML.

Why This Is Wrong

I understand his point but I think that it misses one vital thing:

Data is not an application, and an application is not data.

We are trying to treat a single URLs as both access to a resource and an application.

A good example of how easy it was to generate confusion was that Jacob’s own application treated /Bookmark as “a list of all bookmarks”.

I am not sure if this is a mandated requirement of REST but a “list of bookmarks” is not a “single bookmark”, they are two different things. I realise it’s a common convention but that does not make it correct.

So Jacob’s own application allowed us to inline-edit the bookmark in the URL /Bookmark was incorrect based on his own premise. The URL should have been /Bookmark/{id} to edit a single bookmark, which means REST is saying “the URL /Bookmark can only represent the list and not a single entry.

So this leads to the conclusion that REST requires our application cannot work in a way that differs from the REST constraints. We cannot design a pragmatic application URL structure, it must represent some fixed system. This means the REST conventions are forcing the application designer to follow a fixed convention which in many cases (including Jacob’s own example) is likely to be illogical or unworkable.

Which makes it all but irrelevant.