Using Random Values For Unit Testing

When writing my unit tests I don’t like to use hard coded fixed values because I either end up using the same values or, because of that, tests may succeed by coincidence.

Over time, I have developed an helper class to generate random values for testing.

namespace PauloMorgado.VisualStudio.TestTools.UnitTesting
    public static class RandomGenerator
        public static bool Boolean();
        public static string String();
        public static string String(string prefix);
        public static short Int8();
        public static short Int8(short maxValue);
        public static short Int8(short minValue, short maxValue);
        public static short Int16();
        public static short Int16(short maxValue);
        public static short Int16(short minValue, short maxValue);
        public static int Int32();
        public static int Int32(int maxValue);
        public static int Int32(int minValue, int maxValue);
        public static TEnum Enum<TEnum>();
        public static TEnum EnumFlagsWith<TEnum>(TEnum flagsToAdd);
        public static TEnum EnumFlagsWithout<TEnum>(TEnum flagsToRemove);
        public static TEnum Enum<TEnum>(int maxValue);
        public static TEnum Enum<TEnum>(int minValue, int maxValue);
        public static System.Guid Guid();

This is something that I would like to find on mock frameworks (like Typemock Isolator, Rhino.Mocks or MoQ).

It’s still a work in progress, but if you want to try it, it’s on my MSDN Code Gallery: Random Generator For Unit Testing

More On ASP.NET Validators And Validation Summary Rendering of Properties

On previous posts [^][^] I mentioned the size of ASP.NET validators and validation summary rendering and the fact that expando attributes are being used to add properties. Mohamed also mentions this issue.

Besides the fact that custom attributes aren't XHTML conformant, Firefox differs from Internet Explorer in the way it handles these attributes.

On Internet Explorer, these attributes are converted in string properties of the HTML element. On Firefox, on the other hand, these attributes are only accessible through the attributes collection.

I wonder why I don’t like client-side JavaScript development.

Testing With Multiple Versions Of Internet Explorer

On a previous post I mentioned IETester.

Jorge Moura mentioned TredoSoft’s MultipleIEs and a list of web browsers.

DebugBar, Companion.JS And IETester

Some days ago a colleague of mine pointed out to me this tool (IETester) that allows testing the different rendering and JavaScript engines of Internet Explorer (5.5, 6, 7 and 8beta1) side by side with the installed version.

I haven’t tested IETester yet, but I found two other tools in the site that caught my attention: DebugBar and Companion.JS.

DebugBar is like other tools I use [^] with a few differences. DebugBar is an explorer bar (and docks on the left side of IE) and can’t be undocked but has a JavaScript console and tracks only the HTTP/HTTPS traffic that belongs to the visible web browser tab (IE 7). DebugBar can also spy on other instances of IE like Document Explorer or FeedDemon.

Companion.JS is a Firebug-like tool and was the one that liked the most because it gave me something that I hadn’t: something that kills those annoying scripting error dialogs.

Both DebugBar and Companion.JS claim to be JavaScript debuggers but I couldn’t find any way for setting breakpoints or running scripts step by step. Probably because I have Visual Studio installed on this machine.

Microsoft Source Analysis for C# (aka StyleCop)

I’ve learned from a fellow GASPer of the release of Microsoft Source Analysis for C# (aka StyleCop).

It’s still a work in progress but it’s already very useful.

Pedro Félix Is Blogging

Pedro Félix is blogging about WCF.

Getting .NET 1.1 CLR String Hash Codes In The .NET 2.0 CLR

Everyone knows (or, should know) that values values retrieved from the GetHashCode method should not be persisted for later use, specially with strings, because:

The behavior of GetHashCode is dependent on its implementation, which might change from one version of the common language runtime to another. A reason why this might happen is to improve the performance of GetHashCode. [^]

Nevertheless, code that persist values retrieved from the GetHashCode method for later use can fall on your lap. And if you need to upgrade your code to, for example, use WCF or WF, you have a problem.

The usual solution would be to use Reflector to see how it was done in the 1.1 CLR and implement the same algorithm in the 2.0 runtime.

Unfortunately, the 1.1 implantation isn't managed.

Today, thanks to Nicole, I found System.Collections.Specialized.BackCompatibleStringComparer on the 2.0 CLR. This class implements the 1.1 CLR String.GetHashCode algorithm and can be found in the System.dll and System.Windows.Forms.dll assemblies. You can't use it because it's internal but you can see its implementation using Reflector. You can also see it here.

Now I have a few questions:

Typemock Developers Community Site Updated

Typemock has updated its Developers Community Site with new sections.

Besides the forums, there's a new add-ons page where anyone can share her/his tools or snippets (I guess I'll have to brush up my Typemock Snippets For Visual Studio to add there) and an experts page (guess who's there).

Typemock fan Meet the experts

.NET Reflector Released

Get it from here.

Typemock Isolator v4.2.4 Released

Typemock released version 4.2.4 of its Isolator mock framework.

You can check out the release notes in The Typemock Insider blog and download it from the Typemock Isolator Download page.