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!

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!