VS Unit Test Progress Indication

If you do unit tests (and if not, you should), chance is once in a while a test will, (perhaps by design), take a long time to complete.

Visual Studio’s Unit Testing Framework frontend gives an indication of progress between different tests, but not what the running test is doing (this seems to be the case even for VS2012).

In some cases, for example, when doing a sanity check on generated DB tables, it would be more helpful to know what the current test is doing and perhaps when it will finish.

I’ve had this situation a few times and the solution, although not very elegant, seems to be to spawn your own UI thread that does the job. I haven’t been able to find some ready code to do the job, so I did my own.

As a minimum, you need add a reference to these two assemblies in your test project:

  • System.Windows.Forms
  • System.Drawing

This is because they are required in order to build our UI. With those in place, one just needs to instantiate the UI in a new thread (in Single Threaded Apartment mode). From then on, it’s a matter of updating the form as desired (but keeping in mind we’re doing this across threads, so SetControlPropertyThreadSafe() is required).

The code for all of this can be found on GithHub (of course). Enjoy!

SEPA Deadline

Well, it’s the 3rd February, the first working day after the SEPA deadline and where are we with the migration? Seems that few have move onward, if at all, with articles sprouting on the ‘net discussing this situation.

Why? What made the transition so difficult?

First and foremost, one of the main issues is legacy software. Many companies make use of software which happily played along with plain bank accounts. Not to mention that some of this software was specifically tailored to work with particular banks. This required changing the software, sometimes drastically, to somehow support the new SEPA system. That is, if you were lucky to find the old vendor or whoever created the software in the first place.

The next problem is the IBANs themselves; there’s been little education on the subject. While these numbers or not really complex, they do require some time to get used to. Of course, it does pay off — knowing the validity of a 31-digit number just by looking at the first four digits helps quite a bit.

However, you don’t magically get IBANs out of the original mess of BBANs, bank names and branch codes. The good part is that we have various utilities for generating IBANs. The bad part? They are often incomplete, broken or for some banks, completely nonexistent.

So how’s the situation currently being handled? There are two approaches:

  • Asking clients to cite the IBAN from their bank
  • Passing a huge list of accounts to banks for manual conversion

Guess what? In both cases it takes weeks if not months to complete.

Having seen this mess in person, I decided to try helping out a little bit. Given my (limited) experience with IBANs and local banks, I have built up a simple web service for converting IBANs in seconds.

As to the SEPA Migration? Seems the EC decided to add six more months to the deadline. Will everyone make it till then? Well, I’d like to think the EC will not be extending the deadline anymore — mostly because it is already reflecting badly on the EU economy as it is.

PHP Post-Mortem

PHP is very configurable, but sometimes default settings or those imposed by the framework in use tend to make simple debugging very difficult.

Don’t get me wrong, whenever possible a proper PHP Debugger (extension) is the way to go, but sometimes, when all else fails and you’re facing a blank white page, the snippet below can get you out of the situation in no time.

So, how does it work? While a long time have passed since I first wrote it, little changed in the way it works.

As you might know, in PHP you can register a shutdown handler – a function to be called when PHP is closing down. What you might not know is that this function is called no matter what; even when fatal errors come up. The only exception is if an existing shutdown handler decides to kill the remaining handlers from executing (which is usually rare).

This functionality makes it a good candidate for retrieving interesting information on the current page run, such as:

  • where the initial output started from (useful to find files that cause PHP to start the output)
  • last error message (useful to see fatal errors)
  • the loaded files (useful to find which file caused PHP to stop)

All this is conveniently rendered inside an HTML comment to (hopefully) prevent any end-user from seeing anything out of the ordinary. Of course, use this script with care, it may easily tell too much about your server to the world!